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Előszó 


Amikor 2008. augusztusában elkészültem ennek a könyvnek az első' változatával még problémát okozott átlépni 
a „bűvös" 100 oldalas határt. Ha jól emlékszem, végül 108 oldal lett, szerencsére már csak az Internet egy sötét 
sarkában lehet megtalálni. 

Érdekes módon ezúttal is az oldalszám okozott gondot, igaz, fordult a kocka: valamivel több mint 300 oldalt 
kellett kitöltenem, némi kompromisszum árán sikerrel is jártam. 

Ha jobban belegondolok, az elmúlt 4 évem alapjaiban határozta meg ez a könyv. Rengeteget köszönhetek neki, 
de őszintén szólva néha gyűlöltem is. Valójában most is ezt teszem, hiszen éjjel 11 van és álmos vagyok. 

4 év alatt elképesztő változáson esett át az informatika világa. Ebben a pillanatban is újabb csodák születnek. 
Borzalmasan nehéz lépést tartani a technológia végtelen evolúciójával, szinte lehetetlennek látszó feladat. 
Ennek a könyvnek a célja, hogy olyan alapokat nyújtson, amelyre nyugodtan támaszkodhatunk a kalandos úton, 
amelyet szoftverfejlesztésnek hívnak. 

Több mint 40000 olvasó többszáz jótanácsának, visszajelzésének eredménye az amit most a kezedben tartasz! 
Nem fogok hazudni, ez nem egy mindentudó lexikon és nem is csodalámpa, amit megdörzsölve azonnal fejedbe 
száll a tudás - bár próbálkozni lehet. Tekintsd társnak, jóbarátnak, aki utat mutat, ha elakadtál. Remélem, épp 
annyi örömet okoz majd Neked, mint nekem tette! 

Kötelességem köszönetét mondani mindazoknak, akik hozzájárultak a könyv létrejöttéhez! Sajnos annyi helyem 
nincs, hogy mindenki elférjen, mégis szeretném kiemelni néhányukat: 

Kovács Gyula és Balázs Gábor tanár uraknak, a gyömrői Teleki László Gimnázium és Informatikai Szakközép- 
iskolából. 

Lippé Szabolcsnak és a Microsoft Magyarországnak, köszönöm a lehetőséget, remélem hamarosan elérjük a 
hatszámjegyű letöltésszámot is! 

Ecsegi Szandrának, hogy végig mellettem állt, rámutatott olyan dolgokra, amik nekem eszembe sem jutottak. 
Köszönöm. 

A könyv és a hozzátartozó programozási példák a weben is elérhetőek a Devportal.hu oldalon. 


Tóalmás, 2012. augusztus 


Reiter István 
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Microsoft .NET Framework 


A kilencvenes évek közepén a Sun Microsystems kiadta a Java platform első' nyilvános változatát. Az addigi 
programnyelvek/platformok különböző' okokból nem tudták felvenni a Java-val a versenyt, így számtalan 
fejlesztő döntött úgy, hogy a kényelmesebb és sokoldalúbb Java-t választja. 

Válaszképp a Microsoft a kilencvenes évek végén elindította a Next Generation Windows Services fedőnevű 
projektet, amelyből aztán megszületett a .NET, ami a kissé elavult és nehézkesen programozható COM 
platformot hivatott leváltani (ettől függetlenül a COM ma is létező, viszonylag népszerű eszköz - ez főleg a 
hatalmas szoftverbázisnak köszönhető, minden Windows rendszernek részét képezi, és számos .NET könyvtár is 
épít rá). 

Az évek folyamán a .NET Framework szinte teljesen átvette az uralmat a Microsoft fejlesztői platform¬ 
palettáján. Ott van a hagyományos asztali alkalmazásokban (Windows Forms, WPF), a weben (ASP.NET, 
ASP.NET MVC, Silverlight) és az okostelefonokon is (Windows Phone). 

Nem hagyhatjuk szó nélkül azt sem, hogy az egyes technológiák között meglehetősen egyszerű az átjárás, elég 
csak a WPF-Silverlight-Windows Phone triumvirátusra gondolni. 


A .NET PLATFORM 

Maga a .NET platform a Microsoft, a Flewlett Packard, az Intel és mások közreműködésével megfogalmazott CLI 
(Common Language Infrastructure) egy implementációja. A CLI egy szabályrendszer, amely maga is több részre 
oszlik: 

• A CTS (Common Type System) az adatok kezelését, a memóriában való megjelenést, az egymással való 
interakciót stb. írja le. 

• A CLS (Common Language Specification) a CLI kompatibilis nyelvekkel kapcsolatos elvárásokat 
tartalmazza. 

• A VÉS (Virtual Execution System) a futási környezetet specifikálja, nevezik CLR -nek (Common 
Language Runtime) is. 

Általános tévhit, hogy a VES/CLR -t virtuális gépként azonosítják. Ez abból a szintén téves elképzelésből alakult 
ki, hogy a .NET ugyanaz, mint a Java, csak Microsoft köntösben. A valóságban nincs .NET virtuális gép, helyette 
ún. felügyelt (vagy managed) kódot használ, vagyis a program teljes mértékben natív módon, közvetlenül a 
processzoron fut, mellette pedig ott a keretrendszer, amely felelős pl. a memóriafoglalásért vagy a kivételek 
kezeléséért. 

A .NET nem programozási nyelv, hanem környezet. Gyakorlatilag bármelyik programozási nyelvnek lehet .NET 
implementációja. Jelenleg kb. 50 nyelvnek létezik hivatalosan .NET megfelelője, nem beszélve a számtalan 
hobbifejlesztésről. 


MSIL/CIL 

A "hagyományos" programnyelveken - mint pl. a C++ - megírt programok ún. natív kódra fordulnak le, vagyis a 
processzor számára - kis túlzással - azonnal értelmezhetőek. 

A .NET (akárcsak a Java) más úton jár, a fordító először egy köztes nyelvre (Intermediate Language) fordítja le a 
forráskódot. Ez a nyelv a .NET világában az MSIL, illetve a szabványosítás után a CIL ( MICROSOFT/CommoniL) - 
különbség csak az elnevezésben van. 

Jogos a kérdés, hogy a két módszer közül melyik a jobb? Fia nagy általánosságban beszélünk, akkor a válasz az, 
hogy nincs köztük különbség. Igaz, hogy a natív nyelvek hardver-közelibbek és emiatt gyorsabbak tudnak lenni, 
viszont ez több hibalehetőséggel is jár, amelyek elkerülése a felügyelt környezetben kiegyenlíti az esélyeket. 
Bizonyos területeken viszont egyik vagy másik megközelítés jelentős eltérést eredményezhet. Jó példa a 
számítógépes grafika, ahol a natív nyelvek vannak előnyben pont azért, mert az ilyen számításigényes 
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feladathoz minden csepp erőforrást ki kell préselni a hardverből. Másfelől a felügyelt környezet a hatékonyabb 
memóriakezelés miatt jobban teljesít olyan helyzetekben, ahol nagy mennyiségű adatot mozgatunk a 
memórián belül (pl. számos rendező algoritmus ilyen). 


Fordítás és futtatás 

A natív programok ún. gépi kódra fordulnak le, míg a .NET forráskódokból egy CIL nyelvű futtatható állomány 
keletkezik. Ez a kód a feltelepített .NET Framework -nek szóló utasításokat tartalmaz. Amikor futtatjuk ezeket 
az állományokat, először az ún. JIT (Just-ln-Time) fordító veszi kezelésbe, és lefordítja őket gépi kódra, amit a 
processzor már képes kezelni. 

Amikor "először" fordítjuk le a programunkat, akkor egy ún. Assembly (vagy szerelvény) keletkezik. Ez 
tartalmazza a felhasznált, illetve megvalósított típusok adatait (ez az ún. Metadata), amelyek a futtató 
környezetnek szolgálnak információval (pl. osztályok szerkezete, metódusai, stb.). Egy Assembly egy vagy több 
fájlból is állhat, tipikusan .exe (futtatható állomány) vagy .dll (osztálykönyvtár) kiterjesztéssel. 


BCL 

A .NET Framework telepítésével a számítógépre kerül - többek között - a BCL (Base Class Library), ami az 
alapvető feladatok (fájl olvasás/ írás, adatbázis-kezelés, adatszerkezetek ... stb) elvégzéséhez szükséges 
eszközöket tartalmazza. Az összes többi könyvtár (ADO.NET, WCF, stb...) ezekre épül. 


A C# PROGRAMOZÁSI NYELV 

A C# (ejtsd: szí-sárp) a Visual Basic mellett a .NET fő programozási nyelve. 1999 -ben Anders Hejlsberg 
vezetésével kezdték meg a fejlesztését. 

A C# tisztán objektumorientált, típusbiztos, általános felhasználású nyelv. A tervezésénél a lehető legnagyobb 
produktivitás elérését tartották szem előtt. A nyelv elméletileg platform független (létezik Linux és Mac fordító 
is), de napjainkban a legnagyobb hatékonyságot a Microsoft implementációja biztosítja. 


Alternatív megoldások 

A Microsoft .NET Framework jelen pillanatban csak és kizárólag Microsoft Windows operációs 
rendszerek alatt érhető el. Ugyanakkor a szabványosítás után a CLI specifikáció nyilvános és bárki 
számára elérhető lett, ezen ismeretek birtokában pedig több független csapat vagy cég is létrehozta a 
saját CLI implementációját, bár eddig még nem sikerült teljes mértékben reprodukálni az eredetit. 
Ezen céljukat nehezíti, hogy a Microsoft időközben számos, a specifikációban nem szereplő 
változtatást végzett a keretrendszeren. 


A "hivatalosnak" ECMA szabvány nem feltétlenül tekinthető tökéletes útmutatónak a keretrendszer 
megértéséhez, néhol jelentős eltérések vannak a valósághoz képest. Ehelyett ajánlott a C# nyelv fejlesztői által 
készített C# referencia, amely - bár nem elsősorban a .NET-hez készült - értékes információkat tartalmaz. 


SSCLI 

Az SSCLI (Shared Source Common Language Infrastructure) vagy korábbi nevén Rotor a Microsoft által 
fejlesztett nyílt forrású, keresztplatformos változata a .NET Frameworknek (tehát nem az eredeti lebutított 
változata). Az SSCLI Windows, FreeBSD és Mac OSX rendszereken is fut. 
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Az SSCU-t kimondottan tanulási célra készítette a Microsoft, ezért a licence engedélyez mindenfajta 
módosítást, egyedül a piaci értékesítést tiltja meg. Ez a rendszer nem szolgáltatja az eredeti keretrendszer 
teljes funkcionalitását, jelen pillanatban valamivel a .NET 2.0 mögött jár. 

Az SSCU projektet már nem fejleszti tovább a Microsoft, ettó'l függetlenül a forráskód és a hozzá tartozó 
dokumentációk rendelkezésre állnak, letölthetó'ek a következő' webhelyről: 

http://www.microsoft. com/downloads/details.aspx?Familyld=8C09FD61-3F26-4555-AE17- 

3121B4F51D4D&displaylanq=en 

Mono 

A Mono projekt szülőatyja Miguel de Icaza, 2000-ben kezdte meg a fejlesztést, és egy évvel később mutatta be 
az első kezdetleges C# fordítót. A Ximian (amelyet Icaza és Nat Friedman alapított) felkarolta az ötletet, és 2001 
júliusában hivatalosan is elkezdődött a Mono fejlesztése. 2003 -bán a Novell felvásárolta a Ximian -t, az 1.0 
verzió már Novell termékként készült el egy évvel később. 

2011-ben az Attachmate felvásárolta a Novell-t, ezzel együtt pedig több száz fejlesztőtől - beleértve a Mono 
csapatot - is megváltak. A Mono jövője ekkor kétséges volt, de Icaza alig egy hónapon belül új céget alapított 
Xamarin néven, amely átvette a projektet. 

A Mono pillanatnyilag a 2.10.8 verziószámnál jár, támogatja a C# 4.0 nyelvi elemeit, illetve megvalósítja a 
Microsoft-féle BCL nagy részét. 

A Mono elérhető Windows, Linux, UNIX, BSD, Mac OSX és Solaris rendszereken is. Napjainkban a Mono mutatja 
a legígéretesebb fejlődést, mint a Microsoft .NET jövőbeli "ellenfele", illetve keresztplatformos társa. A Mono 
emblémája egy majmot ábrázol, a szó ugyanis spanyolul majmot jelent. 

A Mono hivatalos oldala: http://www.mono-proiect.com/Main Papé 

DotGNU 

A DotGNU a GNU projekt része, amelynek célja egy ingyenes és nyílt alternatívát nyújtani a Microsoft 
implementáció helyett. Ez a projekt - szemben a Mono -val - nem a Microsoft BCL -lel való kompatibilitást 
helyezi előtérbe, hanem az eredeti szabvány pontos és tökéletes implementációjának a létrehozását. A DotGNU 
saját CLI megvalósításának a Portable .NET nevet adta. A DotGNU projektet már nem fejlesztik tovább. 

A projekt hivatalos oldala: http://www.anu.ora/software/dotgnu/ 
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Ismerkedünk a nyelvvel 


Mielőtt elkezdenénk hosszú utunkat, fel kell fegyverkeznünk a megfelelő fejlesztőeszközzel! A .NET 
programozáshoz a legjobb választás a Microsoft saját terméke, a Visual Stúdió. A „nagy" fizetős változatok 
(Professional, Ultimate) mellett létezik az ingyenes Express család is, amelyek szinte teljes körű szolgáltatást 
nyújtanak. 

Az Express változatok „különlegessége", hogy a nagy változatokkal ellentétben csak egy-egy részterületre 
koncentrálnak, külön változat van a webes és asztali alkalmazások készítéséhez. 


Visual Stúdió 

A jegyzetben a Visual C# Express 2010-et használjuk, bár jelen pillanatban már létezik a Visual Stúdió 11 is, igaz, 
csak béta változatban. Nem kell azonban aggódni, a Visual Stúdió kifejezetten konzisztens felépítésű maradt az 
elmúlt években, aki az egyik változatot tudja használni, az a többivel is elboldogul. 

A Visual C# Express 2010 az alábbi webhelyről tölthető le: 

http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-csharp-express 

A Visual C# Express a telepítés után 30 napig használható, utána regisztrációs kódot fog kérni. Ehhez mindössze 
egy Live ID szükséges (a megadott e-mail cím), ezután kapunk kódot, amelyet beírva immár további 
előfeltételek nélkül tetszés szerint használhatjuk a programot. 

A Visual Stúdió elindításakor tegyük a következőt: 

1. Tools menü-> Settings 

2. A Basic Settings helyett válasszuk az Expert Settings beállítást! 

Ez az egyszerű lépés a későbbiekben még hasznunkra válik majd. 


Hello World! 

Készítsük el első C# nyelven írt programunkat! 

A híres "Hello World!" program elsőként Dennis Ritchie és Brian Kernighan "A C programozási nyelv" című 
könyvében jelent meg, és azóta szinte hagyomány, hogy egy programozási nyelv bevezetőjeként ezt a 
programot mutatják be. 

A Fiié menüben kattintsunk a New Project menüpontra, ekkor a megjelenő ablakban kiválaszthatjuk a projekt 
típusát. A jegyzetben nagyrészt Console Application sablont fogunk használni, ezzel egy parancssorban futó 
programot hozhatunk létre. 
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Az OK gombra kattintva elkészül az első projektünk, a forráskód így néz ki: 


using System; 

using System.Collections.Generic; 
using System.Linq; 
using System.Text; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

} 

} 

} 


Meglepően sok mindent látunk, ahhoz képest, hogy ez a program a világon semmit nem csinál. Menjünk 
sorjában, egyelőre különösebb magyarázat nélkül, a következő fejezetekben mindenre fény derül. Az első négy 
sorral azokat a névtereket jelöltük ki, amelyeket használni szeretnénk. Ebben az esetben a Visual Stúdió egy 
kicsit túlbuzgó volt, egyelőre az első sor is elég lett volna, de nyugodtan hagyjunk mindent, ahogy van, még 
nincs jelentősége. 

A következő lépésben megadjuk a programunk névterét, ez alapértelmezés szerint az lesz, amit a New Project 
ablakban a Name mezőben megadtunk. 

A eláss Program sor az, ami egy kicsit ijesztő lehet a kezdő programozó számára. A C# tisztán objektumorientált 
nyelv, ami egyelőre azt jelenti számunkra, hogy bármit teszünk, azt csakis egy osztályon belül egy függvényben 
vagy metódusban tehetjük. Egy osztályt a eláss kulcsszóval vezetünk be, amely után az osztály nevét kell írnunk. 
Ebben a pillanatban még nem kell ennél többet tudnunk az objektumorientált programozásról, de nemsokára 
ennek is eljön az ideje. 
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Nem maradt más hátra, mint a Main függvény. Ez nagyon fontos összetevője minden C# programnak, hiszen ez 
az alkalmazásunk belépési pontja, itt kezdődik el a futása. Minden C# programnak tartalmaznia kell egy Main 
nevű függvényt, ellenkező esetben le sem fordul. 


Vizsgáljuk meg egy kicsit a fejlesztőeszközt is! 


LifJ TestApp - Microsoft Visual C# 2010 Express 
Fiié Edit View Refactor Project Build Debug Data Tools Window Help 

iaB-iia'ü «g«i-«. - ■ ja - » 


- _3 * B íS ü •, 



Bal oldalon a forráskódot láthatjuk, míg a jobb oldalt az ún. Solution Explorer foglalja el. Minden esetben, 
amikor egy projektet készítünk, egy ún. Solution jön létre. Egy Solution több projektet is tartalmazhat, jobb 
gombbal kattintva hozhatjuk elő a hozzá tartozó helyi menüt, amely segítségével újabb projektet készíthetünk. 
Ugyanígy minden projekthez is tartozik ilyen menü, amellyel pl. új elemeket adhatunk hozzá. 

Látható, hogy egy „faszerű" szerkezetről van szó. A félkövér betűvel kiemelt projekt a StartUp elem, ez fog 
elindulni, ha futtatjuk a Solution-t. Tetszés szerint megváltoztathatjuk ezt a beállítást a kívánt projekt helyi 
menüjében (Set as StartUp project). 

A projekteket „lenyitva" a hozzá tartozó fájlokat találjuk, illetve két mappát, amelyek speciális célt szolgálnak. A 
Properties mappa a programról tartalmaz metaadatokat, például a készítő nevét, az aktuális verziószámot stb. 
A References mappa pedig a projektben használt osztálykönyvtárakat sorolja fel. Ebből rögtön kétféle is van, a 
BCL-hez tartozó könyvtárak (alapbeállítás szerint) nem másolódnak be a program kimeneti mappájába, míg a 
külső könyvtárak igen. Új projekt létrehozásakor is több könyvtárat találunk, ezek közül egyelőre a System és 
System.Core nélkülözhetetlen. 

Ahhoz, hogy a programunkat futtassuk, először le kell fordítanunk. Ezt a Build menüben található Build 
Solution paranccsal tehetjük meg. Ha több projektünk is van, egyenként is fordíthatunk a helyi menüből. 
Amennyiben nem kapunk hibaüzenetet, illetve a bal alsó sarokban megjelenik a Build Succeeded felirat, akkor 
a programunk szintaktikailag helyes, megpróbálhatjuk futtatni. 

Ehhez a Debug menü Start Debugging illetve Start Without Debugging parancsait kell használnunk. Ha a 
projekt a legutóbbi fordítás óta megváltozott, akkor automatikusan le is fordítja a programunkat a Visual 
Stúdió. Használhatunk gyorsbillentyűket is, F6 a fordítás, míg F5 a futtatás (és fordítás, ha szükséges). Végezetül 
szintén elérhetjük a célunk, ha a menüsorban található kis zöld fektetett háromszögre kattintunk. 

Lépjünk tovább, egyelőre a Main függvényen belül fogunk tevékenykedni. Ahhoz, hogy elkészíthessük a 
programunkat, tudnunk kell, hogyan kezelhetjük a parancssort a programunkból. A .NET Framework BCL-e erre 
is kínál megoldást, a Console osztály lesz segítségünkre: 
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using System; 

using System.Collections.Generic; 
using System.Linq; 
using System.Text; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Console.WriteLine("Hello World"); 
Console.ReadKeyQ; 

} 

} 


Örömmel tapasztalhatjuk, hogy a Console szó után tett pont előhozza a választható függvények listáját. Ezt a 
Visual Stúdió IntelliSense-nek hívja. Ha nem ajánlja fel a listát a fejlesztőeszköz, akkor elképzelhető, hogy a 
kódkiegészítés nincs bekapcsolva. A visszakapcsoláshoz a következőket kell tenni: 

1. Tools menü -> Options 

2. Ha nincs bejelölve a „Show All Settings" négyzet, akkor kapcsoljuk be! 

3. Text Editor -> C# -> IntelliSense -> Legyen bejelölve a „Show completion list after a character is typed" 
feliratú négyzet! 

A WriteLine függvény kiírja a parancssorba a paraméterként kapott szöveget, majd új sort nyit. Amennyiben 
szeretnénk ugyanabban a sorban maradni, használjuk a Console.Write függvényt! 

A Console.ReadKey függvény feladata, hogy vár egy billentyűleütést a felhasználótól, mielőtt továbblépne a 
program. Miért van erre szükség? A legegyszerűbb, ha kipróbáljuk a programot nélküle. Amit látni fogunk, az 
egy villanás, hiszen a programunk csak annyit tesz, hogy kiír egy szöveget és kilép. Ez utóbbi miatt kellett 
valami, amivel megszakíthatjuk futását, és itt jön a képbe a ReadKey. 


A C# SZINTAKTIKÁJA 

Amikor egy programozási nyelv szintaktikájáról beszélünk, akkor azokra a szabályokra gondolunk, amelyek 
megszabják a forráskód felépítését. Ez azért fontos, mert az egyes fordítóprogramok csak ezekkel a 
szabályokkal létrehozott kódot tudják értelmezni. Ha a forráskód szintaxisa nem megfelelő, a program nem 
fordul le. 

A C# úgynevezett C-stílusú szintaxissal rendelkezik (azaz a C programozási nyelv szintaxisát veszi alapul), ez 
három fontos szabályt von maga után: 

• Az egyes utasítások végén pontosvessző -; - áll. 

• A kis- és nagybetűk különböző jelentőséggel bírnak, azaz a "program" és "Program" azonosítók 
különböznek. Ha a fenti kódban Console.WriteLine helyett console.writeline -t írnánk, akkor a 
program nem fordulna le. 

• A program egységeit (osztályok, metódusok stb.) ún. blokkokkal jelöljük ki, kapcsos zárójelek ({ és }) 
segítségével. 
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Kulcsszavak 


Szinte minden programnyelv definiál kulcsszavakat, amelyek speciális jelentőséggel bírnak a fordító számára. 
Ezeket az azonosítókat a saját meghatározott jelentésükön kívül nem lehet másra használni, ellenkező esetben 
a fordító hibát jelez. Vegyünk például egy változót, aminek az "int" nevet akarjuk adni! Az "int" név is beépített 
típusra utal, azaz kulcsszó, tehát nem fog lefordulni a program. 


int int; //hiba 


A legtöbb fejlesztőeszköz (így a Visual Stúdió is) megszínezi a kulcsszavakat, ezért könnyű elkerülni a fenti hibát. 
A C# 5.0 már 77 kulcsszót ismer: 


abstract 

default 

foreach 

object 

Sizeof 

unsafe 

as 

delegate 

goto 

operator 

stackalloc 

ushort 

base 

do 

If 

out 

Static 

using 

bool 

double 

implicit 

override 

String 

Virtual 

break 

else 

In 

params 

Struct 

volatile 

byte 

enum 

int 

priváté 

Switch 

void 

case 

event 

interface 

protected 

This 

while 

catch 

explicit 

internál 

public 

Throw 


char 

extern 

Is 

readonly 

True 


checked 

false 

lock 

ref 

Try 


eláss 

finally 

long 

return 

Typeof 


const 

fixed 

namespace 

sbyte 

Uint 


continue 

float 

new 

sealed 

Ulong 


decimai 

fór 

null 

short 

unchecked 



Ezeken kívül létezik még 23 azonosító, amelyeket a nyelv nem tart fenn speciális használatra, de különleges 
jelentéssel bírnak. Amennyiben lehetséges, kerüljük a használatukat "hagyományos" változók, osztályok 
létrehozásánál: 


add 

equals 

group 

let 

Remove 

var 

ascending 

from 

in 

on 

Select 

where 

by 

get 

intő 

orderby 

Set 

yield 

descending 

global 

jóin 

partial 

Value 



Néhányuk a környezettől függően más-más jelentéssel is bírhat, a megfelelő fejezet bővebb információt ad 
majd ezekről az esetekről. 


Megjegyzések 

A forráskódba megjegyzéseket tehetünk. Ezzel egyrészt üzeneteket hagyhatunk (pl. egy metódus leírása) 
magunknak vagy a többi fejlesztőnek, másrészt a kommentek segítségével dokumentációt tudunk generálni, 
ami szintén az első célt szolgálja, csak éppen élvezhetőbb formában. 

Megjegyzéseket a következőképpen hagyhatunk: 


static void Main(string[] args) 

{ 

Console.WriteLine("Hello World"); // Ez egy egysoros komment 
Console.ReadKeyQ; 

/* Ez 

egy 
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többsoros komment */ 

} 


Az egysoros komment a saját sora legvégéig tart, míg a többsoros a "/*" és "*/" párokon belül érvényes. 
Utóbbiakat nem lehet egymásba ágyazni: 


/* 

j**l 

7 


Ez a "kód" nem fordul le. 

A kommenteket a fordító nem veszi figyelembe, tulajdonképpen a fordítóprogram első lépése, hogy a 
forráskódból eltávolít minden megjegyzést. 


Névterek 

A .NET Framework osztálykönyvtárai szerény becslés szerint is legalább tízezer nevet, azonosítót tartalmaznak. 
Ilyen nagyságrenddel elkerülhetetlen, hogy a nevek ne ismétlődjenek. Ekkor egyrészt nehéz eligazodni 
közöttük, másrészt a fordító sem tudná, mikor mire gondolunk. Ennek a problémának a kiküszöbölésére hozták 
létre a névterek fogalmát. Egy névtér tulajdonképpen egy virtuális doboz, amelyben a logikailag összefüggő 
osztályok, metódusok stb. vannak. Nyilván könnyebb megtalálni az adatbázis-kezeléshez szükséges osztályokat, 
ha valamilyen kifejező nevű névtérben vannak (pl. System.Data). 

Névteret magunk is definiálhatunk a namespace kulcsszóval: 


namespace MyNameSpace 

{ 

} 


Ezután a névtérre vagy a program elején a using kulcsszóval, vagy az azonosító elé írt teljes eléréssel 
hivatkozhatunk: 


using MyNameSpace; 
//vagy 

MyNameSpace. Valami 


A jegyzet első felében főleg a System névteret fogjuk használni. 
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VÁLTOZÓK 


Amikor programot írunk, akkor szükség lehet tárolókra, ahová az adatainkat ideiglenesen eltároljuk. Ezeket a 
tárolókat változóknak nevezzük. 

A változók a memória egy (vagy több) cellájára hivatkozó leírók. Egy változót a következő módon hozhatunk 
létre C# nyelven: 


Típus változónév; 


A változónév első karaktere csak betű vagy alulvonás jel (_) lehet, a többi karakter szám is. Lehetőleg kerüljük 
az ékezetes karakterek használatát (bár technikailag nem okoz problémát, nem akadályozza a fordítást)! 
Konvenció szerint a változónevek kisbetűvel kezdődnek. Amennyiben a változónév több szóból áll, akkor 
célszerű azokat a szóhatárnál nagybetűvel "elválasztani" (pl. pirosAlma, vanSapkaRajta stb.). 


Deklaráció és definíció 

Egy változó (illetve lényegében minden objektum) életciklusában megkülönböztetünk deklarációt és definíciót. 
A deklarációnak tartalmaznia kell a típust és azonosítót, a definícióban pedig megadjuk az objektum értékét. 
Értelemszerűen a deklaráció és a definíció egyszerre is megtörténhet. 


int x; // deklaráció 
x = 10; // definíció 
int y = 11; // deklaráció és definíció 


Típusok 

A C# erősen (statikusan) típusos nyelv, ami azt jelenti, hogy minden egyes változó típusának ismertnek kell 
lennie fordítási időben, ezzel biztosítva, hogy a program csakis olyan műveletet hajthat végre, amire valóban 
képes. A típus határozza meg, hogy egy változó milyen értékeket tartalmazhat, illetve mekkora helyet foglal a 
memóriában. 

A következő táblázat a C# beépített típusait tartalmazza, mellettük ott a .NET megfelelőjük, a méretük és egy 
rövid leírás: 


C# típus 

.NET típus 

Méret (byte) 

Leírás 

byte 

System.Byte 

1 

Előjel nélküli 8 bites egész szám (0..255) 

char 

System.Char 

2 

Egy Unicode karakter 

bool 

System.Boolean 

1 

Logikai típus, értéke igaz(l vagy true) vagy hamis(0 
vagy false) 

sbyte 

System.SByte 

1 

Előjeles, 8 bites egész szám (-128..127) 

short 

System.Intl6 

2 

Előjeles, 16 bites egész szám (-32768..32767 

ushort 

System.Uintl6 

2 

Előjel nélküli, 16 bites egész szám (0..65535) 

int 

System.Int32 

4 

Előjeles, 32 bites egész szám (-2147483648.. 
2147483647). 

uint 

System.Uint32 

4 

Előjel nélküli, 32 bites egész szám (0..4294967295) 

float 

System.Single 

4 

Egyszeres pontosságú lebegőpontos szám 

double 

System.Double 

8 

Kétszeres pontosságú lebegőpontos szám 

decimai 

System.Decimai 

16 

Fix pontosságú 28+1 jegyű szám 

long 

System.Int64 

8 

Előjeles, 64 bites egész szám 
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ulong 

System.Uint64 

8 

Előjel nélküli, 64 bites egész szám 

string 

System.String 

N/A 

Unicode karakterek szekvenciája 

object 

System.Object 

N/A 

Minden más típus őse 


A forráskódban teljesen mindegy, hogy a "rendes" vagy a .NET néven hivatkozunk egy típusra. 
Alakítsuk át a "Hello World" programot úgy, hogy a kiírandó szöveget egy változóba tesszük: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

string message = "Hello World"; 

Console.WriteLine(message); 

Console.ReadKeyQ; 

} 

} 

} 


A C# 3.0-tól kezdve már lehetséges egy metódus hatókörében deklarált változó típusának meghatározását a 
fordítóra bízni. Általában olyankor tesszük ezt, amikor hosszú típusnévró'l van szó, vagy nehéz meghatározni a 
típust. Ezt az akciót a var kulcsszóval kivitelezhetjük. 

Ez természetesen nem jelenti azt, hogy úgy használhatjuk a nyelvet, mint egy típustalan környezetet! Abban a 
pillanatban, amikor értéket rendeltünk a változóhoz (ráadásul ezt azonnal meg is kell tennünk), az úgy fog 
viselkedni, mint az ekvivalens típus. Az ilyen változók típusa nem változtatható meg, de a megfelelő' 
típuskonverziók végrehajthatóak. 


int x = 10; // int típusú változó 
var z = 10; // int típusú változó 
z = "string"; //fordítási hiba 
varw; //fordítási hiba 


Lokális és globális változók 

Egy blokkon belül deklarált változó lokális lesz a blokkjára nézve, vagyis a program többi részéből nem látható 
(úgy is mondhatjuk, hogy a változó hatóköre a blokkjára terjed ki). A fenti példában a message egy lokális 
változó, ha egy másik függvényből vagy osztályból próbálnánk meg elérni, akkor a program nem fordulna le. 
Ebben az esetben az IntelliSense sem ajánlaná fel, ez az eszköz tehát erre is segítségünkre van. 

Globális változónak azokat az objektumokat nevezzük, amelyek a program bármely részéből elérhetőek. A C# 
nem rendelkezik a más nyelvekből ismerős globális változóval, mivel deklarációt csak osztályon belül 
végezhetünk. Áthidalhatjuk a helyzetet statikus változók használatával, erről később szó lesz. 


Referencia- és értéktípusok 

A .NET minden típusa direkt vagy indirekt módon a System.Object nevű típusból származik, és ezen belül 
szétoszlik érték- és referencia-típusokra (egyetlen kivétel a pointer típus, amelynek semmiféle köze sincs a 
System.Object-hez). A kettő közötti különbség leginkább a memóriában való elhelyezkedésben jelenik meg. 
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A CLR két helyre tud adatokat pakolni, az egyik a verem (stack), a másik a halom (heap). A stack egy ún. UFO 
(last-in-first-out) adattár, vagyis a legutoljára berakott elem lesz a tetején, kivenni pedig csak a mindenkori 
legfelső elemet tudjuk. A heap nem adatszerkezet, hanem a program által lefoglalt nyers memória, amit a CLR 
tetszés szerint használhat. Minden művelet a stack-ei használja, pl. ha össze akarunk adni két számot, akkor a 
CLR lerakja mindkettőt a stack-be és meghívja a megfelelő utasítást. Ezután kiveszi a verem legfelső két elemét, 
összeadja őket, majd a végeredményt visszahelyezi: 


int x = 10; 
inty = 11; 
x + y 

A verem: 

1 11 1 

1 10 1 ---^összeadás művelet--->|21| 

A referenciatípusok minden esetben a halomban jönnek létre, mert ezek összetett adatszerkezetek, és így 
hatékony a kezelésük. Az értéktípusok vagy a stack-ben vagy a heap-ben vannak attól függően, hogy hol 
deklaráltuk őket. 

Metóduson belül, lokálisan deklarált értéktípusok a verembe kerülnek, a referenciatípuson belül adattagként 
deklarált értéktípusok pedig a halomban foglalnak helyet. 

Nézzünk néhány példát! 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

int x = 10; 

} 

} 

} 


Ebben a "programban" x-et lokálisan deklaráltuk egy metóduson belül, ezért biztosak lehetünk benne, hogy a 
verembe fog kerülni. 


eláss MyCIass 

{ 

priváté int x = 10; 

} 


Most x egy referenciatípuson (esetünkben egy osztályon) belüli adattag, ezért a halomban foglal majd helyet. 


eláss MyCIass 

{ 

priváté int x = 10; 

public void MyMethodQ 

{ 

int y = 10; 

} 

} 
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Ezúttal egy kicsit bonyolultabb a helyzet. Az y nevű változót egy referenciatípuson belül, de egy metódusban, 
lokálisan deklaráltuk, így a veremben fog tárolódni, x pedig még mindig adattag, ezért marad a halomban. 


Meg kell említeni ugyanakkor, hogy a programozó szemszögébó'l a világon semmi jelentó'sége nincs, hogy mi 
hol tárolódik. 


Végül nézzük meg, hogy mi lesz érték- és mi referenciatípus! Értéktípus lesz az összes olyan objektum, 
amelyeket a következő' típusokkal deklarálunk: 

• Az összes beépített numerikus típus (int, byte, double, stb.) 

• A felsorolt típus (enum) 

• Logikai típus (bool) 

• Karakter típus (char) 

• Struktúrák (struct) 

Referenciatípusok lesznek a következők: 

• Osztályok (eláss) 

• Interfész típusok (interface) 

• Delegate típusok (delegate) 

• Stringek 

• Minden olyan típus, amely közvetlen módon származik a System.Object-ből vagy bármely eláss 
kulcsszóval bevezetett szerkezetből. 


Referenciák 

Az érték- illetve referenciatípusok közötti különbség egy másik aspektusa az, ahogyan a forráskódban 
hivatkozunk rájuk. Vegyük a következő kódot: 


int x = 10; 
int y = x; 


Az első sorban létrehoztuk az x nevű változót, a másodikban pedig egy új változónak adtuk értékül x-et. A 
kérdés az, hogy y hova mutat a memóriában: oda, ahol x van, vagy egy teljesen más területre? 

Amikor egy értéktípusra hivatkozunk, akkor ténylegesen az értékét használjuk fel, vagyis a kérdésünkre a válasz 
az, hogy a két változó értéke egyenlő lesz, de nem ugyanazon a memóriaterületen helyezkednek el, tehát y 
máshova mutat, teljesen önálló változó. 



A helyzet más lesz referenciatípusok esetében. Mivel ők összetett típusok, ezért fizikailag lehetetlen lenne az 
értékeikkel dolgozni, így egy referenciatípusként létrehozott változóban tulajdonképpen csak olyan információk 
vannak, amelyek segítségével a CLR képes meghatározni, hogy hol keresse az „igazi" objektumot a 
memóriában. Viszont vigyázzunk, a referenciák nem mutatók (mint például a C++-beli pointerek), tehát azon 
kívül, hogy előhúzzuk a kívánt objektumot, nincs hatásunk a memóriára. Az egyszerűség kedvéért a 
továbbiakban is a „memóriaterületre mutat" kifejezést használjuk. Nézzük meg ezt közelebbről: 
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using System; 

namespace TestApp 

{ 

eláss MyCIass 

{ 

public int x; 

} 

eláss Program 

{ 

static void Main(string[] args) 

{ 

MyCIass s = new MyCIassQ; 

s.x = 10; 

MyCIass p = s; 

p.x = 14; 

Console.WriteLine(s.x); 

Console.ReadKeyQ; 

} 

} 

} 


Vajon mit fog kiírni a program? 

Kezdjük az elejéről! Hasonló a felállás, mint az előző forráskódnál, viszont amikor a második változónak értékül 
adjuk az elsőt, akkor az történik, hogy a p nevű referencia ugyanarra a memóriaterületre hivatkozik majd, mint 
s, vagyis tulajdonképpen annak egy álneve (alias) lesz. Értelemszerűen, ha p módosul, akkor s is így tesz, ezért a 
fenti program kimenete 14 lesz. 



Boxing és unboxing 

Boxing-nak (bedobozolás) azt a folyamatot nevezzük, amely megengedi egy értéktípusnak, hogy úgy 
viselkedjen, mint egy referenciatípus. Korábban azt mondtuk, hogy minden típus közvetlenül vagy indirekt 
módon a System.Object -bői származik. Az értéktípusok esetében az utóbbi teljesül, ami egy igen speciális 
helyzetet jelent. Az értéktípusok alapvetően nem származnak az Object-ből, mivel így hatékony a kezelésük, 
nem tartozik hozzájuk semmiféle "túlsúly" (elméletileg akár az is előfordulhatna ilyenkor, hogy a referencia¬ 
típusokhoz "adott" extrák (syne blokk, metódustábla stb.) több helyet foglalnának, mint a tényleges adat). 

Hogy miért van ez így, azt nagyon egyszerű kitalálni: az értéktípusok egyszerű típusok, amelyek kis mennyiségű 
adatot tartalmaznak, ezenkívül ezeket a típusokat különösen gyakran fogjuk használni, ezért elengedhetetlen, 
hogy a lehető leggyorsabban kezelhessük őket. 

A probléma az, hogy az értéktípusoknak a fentiektől függetlenül illeszkedniük kell a típusrendszerbe, vagyis 
tudnunk kell úgy kezelni őket, mint egy referenciatípust, és itt jön képbe a boxing művelet. Nézzünk egy példát! 
Az eddig használt Console.WriteLine metódus deklarációja így néz ki: 
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public static void WriteLine( 
Object value 


Látható, hogy a paraméter típusa object, ami a System.Object rövidebb elnevezése, vagyis egy referenciatípus. 
Mi történik vajon, ha egy int típusú változót (egy értéktípust) akarunk így kiírni? A WriteLine metódus minden 
típust úgy ír ki, hogy meghívja rajtuk a ToString metódust, amely visszaadja az adott típus string-alakját. A baj 
az, hogy a ToString-et a System.Object deklarálja, ilyen módon a referenciatípusok mind rendelkeznek vele, de 
az értéktípusok már nem. Még nagyobb baj, hogy a ToString hívásához a sima object-ként meghatározott 
változóknak eló' kell keríteniük a tárolt objektum valódi típusát, ami a GetType metódussal történik - amelyet 
szintén a System.Object deklarál -, ami nem is lenne önmagában probléma, de az értéktípusok nem tárolnak 
magukról típusinformációt épp a kis méret miatt. 

A megoldást a boxing művelet jelenti, ami a következőképpen működik: a rendszer előkészít a halmon egy - az 
értéktípus valódi típusának megfelelő - keretet (dobozt), amely tartalmazza az eredeti változó adatait, illetve az 
összes szükséges információt ahhoz, hogy referencia-típusként tudjon működni - lényegében az is lesz. 


Első ránézésre azt gondolná az ember, hogy a dobozolás rendkívül drága mulatság, de ez nem feltétlenül van 
így. A valóságban a fordító képes úgy optimalizálni a végeredményt, hogy nagyon kevés hátrányunk származzon 
ebből a műveletből, néhány esetben pedig nagyjából ugyanazt a teljesítményt érjük el, mint referenciatípusok 
esetében. 


Vegyük észre, hogy az eddigi WriteLine hívásoknál a "konverzió" kérés nélkül - azaz implicit módon - működött 
annak ellenére, hogy érték- és referenciatípusok között nincs szoros reláció! Az ilyen kapcsolatot implicit 
konverzábilis kapcsolatnak nevezzük és nem tévesztendő össze a polimorfizmussal (hamarosan), bár nagyon 
hasonlónak látszanak. 

A következő forráskód azt mutatja, hogy miként tudunk "kézzel" dobozolni: 


int x = 10; 

object boxObject = x; // bedobozolva 
Console.WriteLine("X értéke: {0}", boxObject); 


Itt ugyanaz történik, mintha rögtön az x változót adnánk át a metódusnak, csak éppen egy lépéssel hamarabb 
elkészítettük x referenciatípus kiónját. 

Az unboxing (vagy kidobozolás) a boxing ellentéte, vagyis a bedobozolt értéktípusunkból kinyerjük az eredeti 
értékét: 


int x = 0; 

object obj = x; // bedobozolva 
int y = (int)obj; // kidobozolva 


Az object típusú változón explicit típuskonverziót hajtottunk végre (erről hamarosan), így visszakaptuk az 
eredeti értéket. 

A kidobozolás szintén érdekes folyamat: logikusan gondolkodva azt hinnénk, hogy most minden fordítva 
történik, mint a bedobozolásnál, vagyis a vermen elkészítünk egy új értéktípust és átmásoljuk az értékeket. Ez 
majdnem teljesen igaz, egyetlen apró kivétellel: amikor vissza akarjuk kapni a bedobozolt értéktípusunkat, 
akkor valójában az unbox IL (Intermediate Language) utasítást hívjuk meg, amely egy ún. value-type-pointert 
ad vissza, amely a halomra másolt és bedobozolt értéktípusra mutat. Ezt a címet azonban nem használhatjuk 
közvetlenül a verembe másoláshoz, ehelyett az adatok egy ideiglenes vermen létrehozott objektumba 
másolódnak, majd onnan egy újabb másolás művelettel a számára kijelölt helyre vándorolnak. 

A kettős másolás pazarlásnak tűnhet, de ez egyrészt megkerülhetetlen szabály, másrészt a JIT ezt is képes úgy 
optimalizálni, hogy ne legyen nagy a teljesítményveszteség. 

Fontos még megjegyezni, hogy a bedobozolás után teljesen új objektum keletkezik, amelynek semmi köze az 
eredetihez: 
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int x = 10; 
object z = x; 
z = (int)z + 10; 

Console.WriteLine(x); //10 
Console.WriteLine(z); // 20 


A kimenet 10 illetve 20 lesz. Vegyük észre azt is, hogy z-n konverziót kellett végrehajtanunk az összeadáshoz, de 
az értékadáshoz nem (először kidobozoltuk, összeadtuk a két számot, majd az eredményt visszadobozoltuk). 


Konstansok 

A const típusmódosító kulcsszó segítségével egy objektumot konstanssá, megváltoztathatatlanná tehetünk. A 
konstansoknak egyetlenegyszer adhatunk (és ekkor kötelező is adnunk) értéket, mégpedig a deklarációnál. 
Bármely későbbi próbálkozás fordítási hibát okoz. 


const int x; // Hiba 
const int y = 10; // Ez jó 
x = 11; // Hiba 


A konstans változóknak adott értéket/kifejezést fordítási időben ki kell tudnia értékelni a fordítónak. A 
következő forráskód éppen ezért nem is fog lefordulni: 


Console.WriteLine("Adjon meg egy számot: "); 
const int x = int.Parse(Console.ReadLine()); 


A Console.ReadLine metódus egy sort olvas be a standard bemenetről (ez alapértelmezés szerint a konzol lesz, 
de megváltoztatható), amelyet termináló karakterrel (amely a „sor végét" jelzi, pl. Carriage Return, Line Feed 
stb.), pl. az Enter-rel zárunk. 

A metódus egy string típusú értékkel tér vissza, amelyből ki kell nyernünk a felhasználó által megadott számot. 
Erre fogjuk használni az int.Parse metódust, ami paraméterként egy karaktersorozatot vár, és egész számot ad 
vissza. A paraméterként megadott karaktersor nem tartalmazhat numerikus karakteren kívül mást, ellenkező 
esetben a program kivételt dob. Ennek kiküszöbölésére rendelkezésünkre állnak a TryParse függvények is, ezek 
logikai értéket adnak vissza, amellyel jelzik, hogy a konverzió sikerült vagy sem, utóbbi esetben pedig nem 
dobnak kivételt. 


A FELSOROLT TÍPUS 

A felsorolt típus olyan adatszerkezet, amely meghatározott értékek névvel ellátott halmazát képviseli. Felsorolt 
típust az enum kulcsszó segítségével deklarálhatunk: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

enum Animál { Cat, Dog, Tiger, Wolf}; 

static void Main(string[] args) 

{ 

Console.ReadKeyQ; 

} 
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Enum típust csakis metóduson kívül (osztályon belül vagy "önálló" típusként) deklarálhatunk, ellenkező esetben 
a program nem fordul le. Ezután így használhatjuk: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

enum Animál { Cat, Dog, Tiger, Wolf}; 

static void Main(string[] args) 

{ 

Anima b = Anima .Tiger; 

if (b == Anima .Tiger) // Ha b egy tigris 

{ 

Console.WriteLine("b egy tigris... 1 '); 

} 

Console.ReadKeyQ; 

} 

} 

} 


A felsorolás minden tagjának megfeleltethetünk egy egész (numerikus) értéket. Ha mást nem adunk meg, akkor 
alapértelmezés szerint a számozás nullától kezdődik, és deklaráció szerinti sorrendben (értsd: balról jobbra) 
eggyel növekszik. Ezen a módon az enum objektumokon explicit konverziót hajthatunk végre a megfelelő 
numerikus értékre: 


Animál a = Animál. Cat; 
int x = (int)a; //x == 0 
a = Animál. Wolf; 
x = (int)a; //x == 3 


A tagok értékei alapértelmezetten int típusúak, de ezen változtathatunk: 


enum Animál : byte { Cat, Dog, Tiger, Wolf}; 


Természetesen ez együtt jár azzal, hogy a tagok értékének az adott típus értékhatárai között kell maradniuk, 
vagyis a példában egy tag értéke nem lehet több mint 255. Ilyen módon csakis a beépített egész numerikus 
típusokat használhatjuk (pl. byte, long, uint stb.). Azok a "nevek" amelyekhez nem rendeltünk értéket implicit 
módon, az őket megelőző név értékétől számítva kapják meg azt, növekvő sorrendben. így a lenti példában 
Tiger változó értéke négy lesz: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

enum Animál { Cat = 1, Dog = 3, Tiger, Wolf} 
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static void Main(string[] args) 

{ 

Anima a = Animál. Tiger; 
Console.WriteLine((int)a); // 4 

Console.ReadKeyQ; 

} 

} 

} 


Az Enum.TryParse metódussal string értékekbó'l "gyárthatunk" felsorolt értékeket: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

enum Animál { Cat = 1, Dog = 3, Tiger, Wolf} 

static void Main(string[] args) 

{ 

string sl = "1"; 
string s2 = "Dog"; 

Anima al, a2; 

Enum.TryParse(sl, true, out al); 
Enum.TryParse(s2, true, out a2); 

Console.ReadKeyQ; 

} 

} 

} 


Null típusok 

A referenciatípusok az inicializálás eló'tt automatikusan null értéket vesznek fel, illetve mi magunk is 
megjelölhetjük ó'ket "beállítatlannak": 


using System; 

namespace TestApp 

{ 

eláss MyCIass {} 

eláss Program 

{ 

static void Main(string[] args) 

{ 

MyCIass mc = null; 
Console.ReadKeyQ; 

} 

} 
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Ugyanez az értéktípusoknál már nem alkalmazható: 


int x = null; // ez nem jó 


Azt már láttuk, hogy a referenciatípusokra referenciákkal, azaz a nekik megfelelő memóriacímmel mutatunk, 
ezért lehetséges null értéket megadni nekik. Az értéktípusok pedig az általuk tárolt adatot reprezentálják, ezért 
ők nem vehetnek fel null értéket, mivel az ilyen típusokon ez a fogalom nincs értelmezve. Minden ilyen típus a 
deklarációja pillanatában (néhány kivételtől eltekintve) automatikusan a megfelelő nulla értékre inicializálódik. 
Azonban előfordulhat, hogy mégis szeretnénk, ha ezek a típusok is rendelkeznének egy „nem definiált" 
állapottal, és ebben lesznek segítségünkre a nullable típusok. Ezek ugyan értéktípusok, mégis kaphatnak null 
értéket. 

A nullable típusokat a "rendes" típus után írt kérdőjellel jelezzük: 


int? x = null; // ez már jó 


Egy nullable típusra való konverzió implicit módon (külön kérés nélkül) megy végbe, míg az ellenkező irányban 
explicit konverzióra lesz szükségünk (vagyis ezt tudatnunk kell a fordítóval): 


inty = 10; 

int? x = y; // implicit konverzió 
y = (int)x; // explicit konverzió 


A DINAMIKUS TÍPUS 


Ennek a fejezetnek a teljes megértéséhez szükség van az osztályok, illetve metódusok fogalmára, ezeket egy 
későbbi fejezetben találja meg az olvasó. 


A C# 3.0 verziójáig bezárólag minden változó és objektum statikusan típusos volt, vagyis egyrészt a típust 
fordításkor meg kellett tudnia határozni a fordítónak, másrészt ez futási idő alatt nem változhatott meg. 

A C# 4.0 bevezeti a dynamic kulcsszót, amely használatával dinamikusan típusossá tehetünk objektumokat. Mit 
is jelent ez a gyakorlatban? Lényegében azt, hogy minden dynamic kulcsszóval jelölt objektum bármit megtehet 
fordítási időben, még olyan dolgokat is, amelyek futásidejű hibát okozhatnának. Ezenkívül az összes ilyen 
„objektum" futásidőben megváltoztathatja a típusát is: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

dynamic x = 10; 

Console.WriteLine(x); //x most 10 
x = "szalámi"; 

Console.WriteLine(x); //x most szalámi 
Console.ReadKeyQ; 

} 

} 

} 
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Vegyük a következő osztályt: 


eláss Test 

{ 

public void Method(string s) 

{ 

} 

} 


Ha a fenti metódust meg akarjuk hívni, akkor meg kell adnunk számára egy string típusú paramétert is. Kivéve, 
ha a dynamic-ot használjuk: 


dynamic t = new Test(); 
t.Method(); // ez lefordul 


A fenti forráskód minden további nélkül lefordul, viszont futni nem fog. 

A konstruktőrök nem tartoznak az „átverhető" metódusok közé, akár használtuk a deklarációnál a dynamic-ot, 
akár nem. A paramétereket minden esetben kötelező megadnunk, ellenkező esetben a program nem fordul le. 
Bár a fenti tesztek „szórakoztatóak", valójában nem túl hasznosak. A dynamic „hagyományos" objektumokon 
való használata lényegében nemcsak átláthatatlanná teszi a kódot, de komoly teljesítményproblémákat is 
okozhat, ezért mindenképpen kerüljük el az ilyen szituációkat! 

A dinamikus típusok igazi haszna a más programnyelvekkel - különösen a seript alapú nyelvekkel - való 
együttműködésben rejlik. A dynamic kulcsszó mögött egy komoly platform, a Dynamic Language Runtime (DLR) 
áll (természetesen a dynamic mellett jó néhány osztály is helyet kapott a csomagban). A DLR olyan „típustalan", 
azaz gyengén típusos nyelvekkel tud együttműködni, mint a Lua, JavaScript, PHP, Python vagy Ruby. 
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Operátorok 


Amikor programozunk, utasításokat adunk a számítógépnek. Ezek az utasítások kifejezésekből állnak, a 
kifejezések pedig operátorokból és operandusokból, illetve ezek kombinációjából jönnek létre: 


i = x + y; 


Ebben az utasításban i-nek értékül adjuk x és y összegét. Két kifejezés is van az utasításban: 

• 1. lépés! x + y -> ezt az értéket jelöljük * -gal 

• 2. lépés: i = * -> i értékéül adjuk a * -ot 

Az első esetben x és y operandusok, a '+' jel pedig az összeadás művelet operátora. Ugyanígy a második 
pontban i és * (vagyis x + y) az operandusok, az értékadás művelet ('=') pedig az operátor. 

Egy operátornak nemcsak két operandusa lehet. A C# nyelv egy- (unáris) és három-operandusú (ternáris) 
operátorokkal is rendelkezik. 

A következő fejezetekben megismerkedünk néhány operátorral, de nem az összessel. Ennek oka az, hogy 
bizonyos operátorok önmagukban nem hordoznak jelentést, egy-egy speciális részterület kapcsolódik hozzájuk. 
Ezért ezeket az operátorokat majd a megfelelő helyen vizsgáljuk meg (pl. az indexelő operátor most kimarad, 
elsőként a tömböknél találkozhat majd vele a kedves olvasó). 


Operátor-precedencia 

Amikor több operátor is szerepel egy kifejezésben, a fordítónak muszáj valamilyen sorrendet (ún. precedenciát) 
felállítani közöttük, hiszen az eredmény ettől is függhet. Például: 


10 * 5 + 1 


Ennél a kifejezésnél - sorrendtől függően - az eredmény lehet 51 vagy 60. A jó megoldás az előbbi, az 
operátorok végrehajtásának sorrendjében a szorzás és az osztás előnyt élvez (természetesen érvényesülnek a 
matematikai szabályok). A legelső sorrendi helyen szerepelnek pl. a zárójeles kifejezések, utolsón pedig az 
értékadó operátor. Ha bizonytalanok vagyunk a végrehajtás sorrendjében, akkor mindig használjunk 
zárójeleket, ez a végleges programra nézve semmilyen hatással nincs (és a forráskód olvashatóságát is javítja). 

A fenti kifejezés így nézne ki helyesen zárójelezve: 


(10 * 5) + 1 


A C# nyelv precedencia szerint 14 kategóriába sorolja az operátorokat (a kisebb sorszámút értékeli ki hamarabb 
a fordító): 

1. Zárójel, adattag hozzáférés (pont ('.') operátor), metódushívás, postfix inkrementáló és dekrementáló 
operátorok, a new operátor, typeof, sizeof, checked és unchecked 

2. Pozitív és negatív operátorok (x = -5), logikai és bináris tagadás, prefix inkrementáló és dekrementáló 
operátorok, explicit típuskonverzió 

3. Szorzás, maradékos és maradék nélküli osztás 

4. Összeadás, kivonás 

5. Bit-eltoló (» és «) operátorok 

6. Kisebb (vagy egyenlő), nagyobb (vagy egyenlő), as, is 

7. Egyenlő és nem egyenlő operátorok 

8. Logikai ÉS 
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9. Logikai XOR 

10. Logikai VAGY 

11. Feltételes ÉS 

12. Feltételes VAGY 

13. Feltételes operátor ( ? :) 

14. Értékadó operátor, illetve a "rövid formában" használt operátorok (pl: x +=y) 

Értékadó operátor 

Az egyik legáltalánosabb művelet, amit elvégezhetünk az, hogy egy változónak értéket adunk. A C# nyelvben 
ezt az egyenlőségjel segítségével tehetjük meg: 


int x = 10; 


Létrehoztunk egy int típusú változót, elneveztük x-nek, majd kezdőértékének tízet adtunk. Természetesen nem 
kötelező a deklarációnál megadni a definíciót (amikor meghatározzuk, hogy a változó milyen értéket kapjon), 
ezt el lehet halasztani: 


int x; 
x= 10; 


Ennek ellenére ajánlott akkor értéket adni egy változónak, amikor deklaráljuk. 

Egy változónak nemcsak konstans értéket, de egy másik változót is értékül adhatunk, de csakis abban az 
esetben, ha a két változó azonos típusú, illetve ha létezik megfelelő konverzió (a típuskonverziókkal egy későbbi 
fejezet foglalkozik). 


int x = 10; 

int y = x; // y értéke most 10 


Matematikai operátorok 

A következő példában a matematikai operátorok használatátvizsgáljuk meg: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

int x = 10; 
int y = 3; 

int z = x + y; // Összeadás: z = 10 + 3 
Console.WriteLine(z); // Kiírja az eredményt: 13 
z = x - y; // Kivonás: z = 10 - 3 
Console.WriteLine(z); // 7 
z = x * y; //Szorzás: z = 10 * 3 
Console.WriteLine(z);//30 
z = x / y; // Maradék nélküli osztás: z = 10 / 3; 
Console.WriteLine(z); // 3 
z = x % y; // Maradékos osztás: z = 10 % 3 
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Console.WriteLine(z); // Az osztás maradékát írja ki: 1 
Console.ReadKeyQ; //Vár egy billentyű leütésére 

} 

} 

} 


Relációs operátorok 

A relációs operátorok segítségével egy adott értékkészlet elemei közötti viszonyt tudjuk lekérdezni. Relációs 
operátort használó műveletek eredménye vagy igaz (true) vagy hamis (false) lesz. A numerikus típusokon 
értelmezve van egy rendezés reláció: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

int x = 10; 
int y = 23; 

Console.WriteLine(x > y); // Kiírja az eredményt: false 
Console.WriteLine(x == y); // false 
Console.WriteLine(x != y); // x nem egyenlő' y -nal: true 
Console.WriteLine(x <= y); // x kisebb-egyenlő mint y: true 

Console.ReadKeyQ; 

} 

} 

} 


Az első sor egyértelmű, a másodikban az egyenlőséget vizsgáljuk a kettős egyenlőségjellel. Ilyen esetekben 
figyelni kell, mert egy elütés is nehezen kideríthető hibát okoz, amikor egyenlőség helyett az értékadó 
operátort használjuk. Az esetek többségében ugyanis így is lefordul a program, működni viszont valószínűleg 
rosszul fog. 

A relációs operátorok összefoglalása: 


x > y 

x nagyobb, mint y 

x >= y 

x nagyobb vagy egyenlő, mint y 

x < y 

x kisebb, mint y 

x <= y 

x kisebb vagy egyenlő, mint y 

x == y 

x egyenlő y-nal 

x != y 

x nem egyenlő y-nal 


Logikai és feltételes operátorok 

A C# logikai típusa (bool) két értéket képes felvenni: igaz (true) és hamis (false). Ennek a típusnak a segítségével 
elvégezhetőek a szokásos logikai műveletek, ezeket nézzük most meg. 


using System; 
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namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

bool I = true; 
bool k = false; 

if (I == true && k == false) 

{ 

Console.WriteLine("lgaz"); 

} 

Console.ReadKeyQ; 

} 

} 

} 


A fenti példában először felvettünk két logikai változót, az elsőnek „igaz", a másodiknak „hamis" értéket 
adtunk. Ezután egy elágazás következik, erről bővebben egy későbbi fejezetben lehet olvasni, a lényeg az, hogy 
ha a zárójelben megadott feltétel igaz, akkor végrehajtja a blokkjában lévő utasítás(oka)t. 

A példában az „ÉS" (&&) operátort használtuk, ez két operandust vár, és akkor ad vissza „igaz" értéket, ha 
mindkettő „igaz" értéket képvisel. Ebből következik az is, hogy akár az előző fejezetben megismert relációs 
operátorokból felépített kifejezések vagy matematikai formulák is lehetnek operandusok. A program nem sok 
mindent tesz, csak kiírja, hogy „Igaz". Nézzük az „ÉS" igazságtáblázatát: 


A 

B 

Eredmény 

hamis 

hamis 

hamis 

hamis 

igaz 

hamis 

igaz 

hamis 

hamis 

igaz 

igaz 

igaz 


A fenti forráskód jó gyakorlás az operátor-precedenciához, az elágazás feltételében először az egyenlőséget 
fogjuk vizsgálni (a hetes számú kategória) és csak utána a feltételes ÉS-t (tizenegyes kategória). 


A második operátor a „VAGY" (11): 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

bool I = true; 
bool k = false; 

if (I == true 11 k == true) 

{ 

Console.WriteLine("lgaz"); 

} 

Console.ReadKeyQ; 
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} 


} 


} 


A „VAGY" (||) operátor akkor térít vissza „igaz" értéket, ha az operandusai közül legalább az egyik „igaz". Ez a 
program is ugyanazt csinálja, mint az előző, a különbség a feltételben van. Látható, hogy k biztosan nem „igaz", 
hiszen éppen előtte kapott „hamis" értéket. A „VAGY" igazságtáblázata: 


A 

B 

Eredmény 

hamis 

hamis 

hamis 

hamis 

igaz 

igaz 

igaz 

hamis 

igaz 

igaz 

igaz 

igaz 


Az eredmény kiértékelése az ún. „lusta kiértékelés" (vagy „rövidzár") módszerével történik, azaz a program csak 
addig vizsgálja a feltételt, amíg muszáj. Tudni kell azt is, hogy a kiértékelés mindig balról jobbra halad, ezért pl. 
a fenti példában k soha nem fog kiértékelődni, mert I van az első helyen, és mivel ő „igaz" értéket képvisel, 
ezért a feltétel is biztosan teljesül. 

A harmadik a „tagadás" vagy negáció (!): 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

int x = 10; 

if (!(x == 11)) 

{ 

Console.WriteLine("X nem egyenlő 11 -gyei!"); 

} 

Console.ReadKeyQ; 

} 

} 

} 


Ennek az operátornak egy operandusa van (ez a példában a zárójelben lévő kifejezés), és akkor ad vissza igaz 
értéket, ha az operandusban megfogalmazott feltétel hamis. A „tagadás" igazságtáblája: 


A 

Eredmény 

hamis 

igaz 

igaz 

hamis 


Ez a három operátor ún. feltételes operátor, közülük pedig az „ÉS" és a „VAGY" operátoroknak létezik 
„csonkolt" logikai párja is. A különbség annyi, hogy a logikai operátorok az eredménytől függetlenül kiértékelik 
a teljes kifejezést, nem élnek a lusta kiértékeléssel. 

A logikai „VAGY" művelet: 


if (I == true | k == true) 

{ 

Console.WriteLine("lgaz M ); 
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} 


A logikai „ÉS": 


if (I == true & k == false) 

{ 

Console.WriteLine("lgaz"); 

} 


A logikai operátorok családjához tartozik (ha nem is szorosan) a feltételes operátor. Ez az egyetlen 
háromoperandusú (ternáris) operátor, és a következőképpen működik: 



Az operátor úgy működik, hogy a kérdőjel előtti kifejezést kiértékeli, majd megnézi, hogy a kifejezés igaz vagy 
hamis. Ha igaz, akkor a kérdőjel utáni érték lesz a teljes kifejezésünk értéke, ha pedig hamis, akkor a kettőspont 
utáni. Természetesen a két kifejezés ugyanazt a típust kell, hogy képviselje, ellenkező esetben nem fordul el a 
program. 

Egyszerűbb if-else (erről később) ágakat lehet általa kiváltani, sok gépelést megspórolhatunk vele és a kódunk is 
kompaktabb, áttekinthetőbb lesz tőle. 


Bit operátorok 

Az előző fejezetben említett logikai operátorok bitenkénti műveletek elvégzésére is alkalmasak. A számítógép 
az adatokat kettes számrendszerbeli alakban tárolja, így például ha van egy byte típusú változónk (ami egy 
byte, azaz 8 bit hosszúságú), aminek a „2" értéket adjuk, akkor az a következőképpen jelenik meg a 
memóriában: 

2 -> 00000010 

A bit operátorok ezzel a formával dolgoznak. Az eddig megismert kettő mellé jön négy másik operátor is. A 
műveletek: 

Bitenkénti „ÉS": veszi a két operandus bináris alakját, és a megfelelő bitpárokon elvégzi az „ÉS" műveletet, azaz 
ha mindkét bit 1 állásban van, akkor az adott helyen az eredményben is az lesz, egyébként pedig 0: 


01101101 
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00010001 AND 

00000001 


Elég egyértelmű, hogy az „ÉS" igazságtáblát használtuk az eredmény kiszámolásához. 
Példa: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Console.Writeüne(10 & 2); // 1010 & 0010 = 0010 = 2 
Console.ReadKeyQ; 

} 

} 

} 


A programot futtatva látni fogjuk, hogy a Console.WriteLine a művelet eredményét tízes számrendszerben írja 
majd ki. 

A bitenkénti „VAGY" hasonlóan működik, mint az „ÉS", de a végeredményben egy bit értéke akkor lesz 1, ha a 
két operandus adott bitje közül valamelyik legalább az: 


01101101 
00010001 OR 

01111101 


Példa a „VAGY"-ra: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Console.WriteLine(10 | 2); // 1010 | 0010 = 1010 = 10 
Console.ReadKeyQ; 

} 

} 

} 


Biteltolás balra: a kettes számrendszerbeli alak „felső"' bitjét eltoljuk, majd a jobb oldalon keletkező „üres" bitet 
nullára állítjuk. Az operátor jele: «. 


10001111 LEFTSHIFT 
100011110 

Példa: 
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using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

int x = 143; 

Console.WriteLine(x « 1); // 10001111 (=143) « 1 = 100011110 = 286 
Console.ReadKeyQ; 

} 

} 

} 


Amikor biteltolást végzünk, figyelnünk kell arra, hogy a művelet végeredménye minden esetben 32 bites, 
előjeles szám (int) lesz. Ennek nagyon egyszerű oka az, hogy így biztosítja a .NET, hogy az eredmény elférjen (a 
fenti példában használt 143 pl. pontosan 8 biten felírható szám, azaz egy byte típusban már nem férne el az 
eltolás után, hiszen akkor 9 bitre lenne szükségünk). 

Biteltolás jobbra: most az alsó bitet toljuk el, és felül pótoljuk a hiányt. Az operátor: ». Példa: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

byte x = 143; 

Console.WriteLine(x » 1); // 10001111 (=143) » 1 = 01000111 = 71 
Console.ReadKeyQ; 

} 

} 

} 


Vegyük észre, hogy amíg a balra való eltolás ténylegesen - fizikailag - hozzátett az eredeti számunkhoz, addig a 
jobbra tolás elvesz belőle, hiszen a „felülre" érkező nulla bitek nem hasznosulnak az eredmény szempontjából! 
Értelemszerűen a balra tolás ezért mindig növelni, a jobbra tolás pedig mindig csökkenteni fogja az eredményt. 

Ennél is tovább mehetünk, felfedezve a biteltolások valódi hasznát: egy n bittel balra tolás megfelel az alapszám 
2 az n-edik hatványával való szorzásnak: 

143 « 1 = 143 * (2 A 1) = 286 
143 « 2 = 143 * (2 A 2) = 572 

Ugyanígy a jobbra tolás ugyanazzal a hatvánnyal oszt (nullára kerekítéssel): 

143 » 1 = 143 / (2 A 1) =71 
143 » 2 = 143 / (2 A 2) = 35 
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Amikor olyan programot készítünk, amely erősen épít kettővel vagy hatványaival való szorzásra/osztásra, akkor 
ajánlott bitműveleteket használni, mivel ezeket a processzor sokkal gyorsabban végzi el, mint a hagyományos 
szorzást (tulajdonképpen a szorzás a processzor egyik leglassabb művelete). 


Rövid forma 

Vegyük a következő példát: 


x = x + 10; 


Az x nevű változót megnöveltük tízzel. Csakhogy ez a megoldás nem túl hatékony. Mi történik valójában? 
Elsőként értelmezni kell a jobb oldalt, azaz ki kell értékelni x-et, hozzá kell adni tízet, és eltárolni a veremben. 
Ezután ismét kiértékeljük x-et, ezúttal a bal oldalon. 

Szerencsére van megoldás, mégpedig az ún. rövid forma. A fenti sorból ez lesz: 


x + = 10; 


Rövidebb, szebb és hatékonyabb. Az összes aritmetikai operátornak létezik rövid formája. 


Az igazsághoz azért az is hozzátartozik, hogy a fordítóprogram elvileg felismeri a fent felvázolt szituációt, és a 
rövid formával egyenértékű IL -t készít belőle (más kérdés, hogy a forráskód így viszont szebb és olvashatóbb). 


A probléma ugyanaz, de a megoldás más a következő esetben: 


x = x + 1; 


Szemmel láthatóan ugyanaz a baj, azonban az eggyel való növelésre/csökkentésre van önálló operátorunk: 


++x és — x 
x++ és x- 


Ebből az operátorból rögtön két verziót is kapunk, prefixes (++/-- elöl) és postfixes (++/— hátul) formát. A 
prefixes alak pontosan azt teszi, amit elvárunk tőle, azaz megnöveli (vagy csökkenti) az operandusát eggyel. 

A postfixes forma egy kicsit bonyolultabb, elsőként létrehoz egy átmeneti változót, amiben eltárolja az 
operandusa értékét, majd megnöveli eggyel az operandust, végül visszaadja az átmeneti változót. Ez elsőre 
talán nem tűnik hasznosnak, de vannak helyzetek, amikor lényegesen megkönnyíti az életünket a használata. 

Attól függően, hogy növeljük vagy csökkentjük az operandust, inkrementáló illetve dekrementáló operátorról 
beszélünk. Ez az operátor használható az összes beépített numerikus típuson, valamint a char illetve enum 
típusokon is, mivel ezeknek van numerikus megfelelőjük. 

Egyéb operátorok 

Unáris ('+' és'-'): az adott szám pozitív illetve negatív értékét jelezzük vele: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 
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{ 

int x = 10; 
int y = 10 + (-x); 

Console.WriteLine(y); 

Console.ReadKeyQ; 

} 

} 

} 


Ez a program nullát fog kiírni (természetesen érvényesülnek a matematikai szabályok). Ezeket az operátorokat 
csakis előjeles típusokon használhatjuk, mivel az operátor int típussal tér vissza (akkor is, ha pl. byte típusra 
alkalmaztuk). A következő két sor fordítási hibát okoz, mivel az int típus nem fér el a byte típusban: 


byte x = 10; 
byte y = -x; 


A typeof az operandusa típusát adja vissza: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

int x = 143; 

if (typeof(int) == x.GetTypeQ) 

{ 

Console.WriteLine("x típusa int"); 

} 

Console.ReadKeyQ; 

} 

} 

} 


A változón meghívott GetType metódus a változó típusát adja vissza (ez egy System. Object-hez tartozó 
metódus, így a használatához dobozolni kell az objektumot). 

A sizeof operátor a „paramétereként" megadott értéktípus méretét adja vissza byte-ban. Ez az operátor 
kizárólag unsafe (Id. Unsafe mód fejezet) módban használható és csakis értéktípusokon (illetve pointer 
típusokon): 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

unsafe 

{ 
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Console.WriteLine(sizeof(int)); 

} 

Console.ReadKeyQ; 

} 

} 

} 


Ez a program négyet fog kiírni, hiszen az int típus 32 bites, azaz 4 byte méretű típus. A programot az unsafe 
kapcsolóval kell lefordítanunk parancssorból való fordításkor: 


esc /unsafe main.cs 


Illetve ha Visual Studio-val dolgozunk, akkor kattintsunk jobb gombbal a Solution Explorerben a projekten, és 
válasszuk a Properties elemet: 




BuilH 
Rebuíld 
Publish... 

Add 

Add Reference... 

Add Service Reference... 
Set as StartUp Project 
Debug 

Cut 



Solution Explorer 

Kb | £ ifl 

^3 Solution 'TestAppl' (1 project) 


¥ x 


mi 


P 1 

>erties 

xences 

iram.cs 


Ctrl+X 

CtrkV 

Del 



Project Fiié 

Project Folder 


TestAppl.csproj 

C:\Users\Reiter\documeni 


Ezután a megnyíló „oldalban" a Build fülön jelöljük be az „Allow unsafe code" négyzetet: 


TestAppl X | 

Application 

Build 


Program.es 


General 


Build Events 
Debug 
Resources 
Settings 


Conditional compilation symbols: 

Define DEBUG constant 
[71 Define TRACE constant 
VJ Allow unsafe code 
[71 Optimize code 
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Vezérlési szerkezetek 


Vezérlési szerkezetnek a program utasításainak sorrendiségét szabályozó konstrukciókat nevezzük. 


Szekvencia 

A legegyszerűbb vezérlési szerkezet a szekvencia. Ez tulajdonképpen egymás után megszabott sorrendben 
végrehajtott utasításokból áll. A szekvencia minden más vezérlési szerkezet épító'köve. 


Elágazás 

Gyakran előfordul, hogy meg kell vizsgálnunk egy állítást, és attól függó'en, hogy igaz vagy hamis, a programnak 
más-más utasítást kell végrehajtania. Ilyen esetekben elágazást használunk: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

int x = 10; 

if (x == 10) // Ha x egyenlő' 10-zel 

{ 

Console.WriteLinef'x értéke 10"); 

} 

Console.ReadKeyQ; 

} 

} 

} 


Az elágazás feltételében az egyenlőség operátort használtuk, és ide kapcsolódik egy viszonylag gyakori hiba: ha 
véletlenül csak „sima" egyenlőségjelet írunk, az fordítási hibának minősül: 


if (x = 10) // hiba 

{ 

} 


Vannak nyelvek, amelyek ezt a formát is megengedik, ezzel automatikusan értéket adva a feltételben szereplő 
változónak, de a C# nem ilyen. 

A feltételben szereplő kifejezésnek minden esetben logikai értéket kell visszaadnia, vagy pedig az eredménynek 
konvertálhatónak kell lennie bool típusra. 

A feltételbe nem írhatunk numerikus értéket visszaadó kifejezést, illetve null értéket sem vizsgálhatunk pusztán 
a referencia nevének megadásával: 
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using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

int x = 11; 

if (x) // ez nem fordul le 

{ 

} 

if (x > 0) // ez már jó 

{ 

} 

Program p = null; 

if (Ip) // ez sem fordul le 

{ 

} 

if (p == null) // ez már jó 

{ 

} 

Console.ReadKeyQ; 

} 

} 

} 


Természetes az igény arra is, hogy azt a helyzetet is kezelni tudjuk, amikor x értéke nem tíz. Ilyenkor használjuk 
az else ágat: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

int x = 11; 

if (x == 10) // Ha x egyenlő' 10-zel 

{ 

Console.WriteLine("x értéke 10"); 

} 

else // Ha pedig nem 

{ 

Console.WriteLine("x értéke nem 10"); 

} 

Console.ReadKeyQ; 


47 




} 

} 

} 


Az else szerkezet akkor lép működésbe, ha a hozzá kapcsolódó feltétel(ek) nem igaz(ak). Önmagában else ág 
nem állhat, nem is lenne sok értelme. 

A fenti helyzetben írhattuk volna ezt is: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

int x = 11; 

if (x == 10) // Ha x egyenlő 10-zel 

{ 

Console.WriteLine("x értéke 10"); 

} 

if (x != 10) // Ha pedig x nem 10 

{ 

Console.WriteLine("x értéke nem 10"); 

} 


Console.ReadKeyQ; 

} 

} 

} 


Ez a program pontosan ugyanazt csinálja, mint az előző, de van egy nagy különbség közöttük: mindkét feltételt 
ki kell értékelnie a programnak, hiszen két különböző szerkezetről beszélünk (ez egyúttal azzal is jár, hogy a 
feltételtől függően mindkét állítás lehet igaz). 

Arra is van lehetőségünk, hogy több feltételt is megvizsgáljunk, ekkor else-if szerkezetet használunk: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

int x = 13; 

if (x == 10) // ha x értéke 10 

{ 

Console.WriteLine("x értéke 10"); 

} 

else if (x == 12) // vagy 12 

{ 

Console.WriteLine("x értéke 12"); 

} 
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else // ha pedig valami más 

{ 

Console.WniteLine("x értéke nem 10 vagy 12"); 

} 


} 


} 


Console. ReadKey(); 

} 


A program az első olyan ágat hajtja végre, amelynek a feltétele teljesül (vagy ha egyik feltétel sem bizonyult 
igaznak, akkor az else ágat - ha adtunk meg ilyet). 

Egy elágazásban pontosan egy darab if, bármennyi else-if és pontosan egy else ág lehet. Egy elágazáson belül is 
írhatunk elágazást. 

Az utolsó példában olyan változót vizsgáltunk, amely nagyon sokféle értéket vehet fel. Nyilván ilyenkor nem 
tudunk minden egyes állapothoz feltételt írni (pontosabban tudunk, csak az nem lesz szép). Ilyen esetekben 
azonban van egy egyszerűbb és elegánsabb megoldás, mégpedig a switch-case szerkezet. Ezt akkor használjuk, 
ha egy változó több lehetséges állapotát akarjuk vizsgálni: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

int x = 11; 

switch (x) 

{ 

case 10: 

Console. WriteLine("x értéke 10"); 
break; 
case 11: 

Console. WriteLine("x értéke 11"); 
break; 

} 

Console .ReadKey(); 

} 

} 

} 


A switch szerkezeten belül megadhatjuk azokat az állapotokat, amelyekre reagálni szeretnénk. Az egyes esetek 
utasításai után meg kell adnunk, hogy mi történjen ezután. Az ágak a kijelölt feladatuk végrehajtása után a 
break utasítással kilépnek a szerkezetből. 

Természetesen nem kell minden lehetséges állapotot megvizsgálnunk, csak azokat, amelyek számunkra 
érdekesek. A fenti példában elég nagy bajban is lennénk, ha minden egyes számot külön akarnánk vizsgálni. 
Erre a célra használhatjuk a default ágat, amely gyakorlatilag az else ágnak felel meg. 

Ha nincs olyan ág, amely kezelné az éppen aktuális értéket, akkor vagy a default ág kapja meg a vezérlést, vagy 
ha nem írtunk ilyet, akkor a switch szerkezetből kilépve folytatódik a program futása. 


using System; 
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namespace TestApp 

{ 

eláss Program 

{ 

enum Animál { TIGER, WOLF, CAT, DOG }; 

static void Main(string[] args) 

{ 

Animál animal = Animál. DOG; 

switch (animal) 

{ 

case Animal. TIGER: 

Console.WriteLine( "Tigris") ; 
break; 
default : 

Console.WriteLine("Nem ismerem ezt az állatot!"); 
break; 

} 

Console .ReadKey(); 

} 

} 

} 


A C++ nyelvtől eltérően a C# nem engedélyezi, hogy break utasítás hiányában egyik állapotból átcsússzunk egy 
másikba. Ez alól a szabály alól egyetlen kivétel van, ha az adott ág nem tartalmaz semmilyen utasítást: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

enum Animal { TIGER, WOLF, CAT, DOG }; 

static void Main(string[ ] args) 

{ 

Animal animal = Animal. DOG; 

switch (animal) 

{ 

case Animal. TIGER: 
case Animal. DOG: 
default : 

Console. WriteLine( "Ez egy állat!"); 
break; 

} 

Console. ReadKeyQ; 

} 

} 

} 


A break utasításon kívül használhatjuk a goto-t is, ekkor átugrunk a megadott ágra: 


using System; 
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namespace TestApp 

{ 

eláss Program 

{ 

enum Animál { TIGER, WOLF, CAT, DOG }; 

static void Main(string[] args) 

{ 

Animál animal = Animál. DOG; 

switch (animal) 

{ 

case Animal. TIGER: 

goto default; 
case Animal. DOG: 

goto default; 
default : 

Console.WriteLine("Ez egy állat!"); 
break; 

} 


Console .ReadKey(); 

} 

} 

} 


Ciklus 

Amikor egy adott utasítássorozatot egymás után többször kell végrehajtanunk, akkor ciklust használunk. A C# 
négyféle ciklust biztosít számunkra. 

Fór ciklus 

Az első az ún. számlálós ciklus (nevezzük for-ciklusnak). Nézzük a következő programot: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

fór (int i = 0; i < 10; ++i) 

{ 

Console.WriteLine(i); 

} 

Console. ReadKeyQ; 

} 

} 

} 


Vajon mit ír ki a program? Mielőtt ezt megmondanám, először inkább nézzük meg azt, hogy mit csinál: a fór 
utáni zárójelben találjuk az ún. ciklusfeltételt, ez minden ciklus része lesz, és azt adjuk meg benne, hogy milyen 
feltétele van a ciklus futásának. A számlálós ciklus feltétele első ránézésre eléggé összetett, de ez ne tévesszen 
meg minket, valójában nem az. Mindössze három kérdésre kell választ adnunk: Honnan? Meddig? Hogyan? 
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Menjünk sorjában: a „Honnan?"-ra adott válaszban megmondjuk azt, hogy milyen típust használunk a 
számoláshoz és azt, hogy honnan kezdjük a számolást. Tulajdonképpen ebben a lépésben adjuk meg az ún. 
ciklusváltozót, amelyre a ciklusfeltétel épül. A fenti példában egy int típusú ciklusváltozót hoztunk létre a 
ciklusfeltételen belül, és nulla kezdó'értéket adtunk neki. 


A ciklusváltozó neve konvenció szerint i lesz az angol iterate - ismétel szóból. Több ciklusváltozó használatakor 
általában i, j, k,... sorrendet követünk. 


Mivel a ciklusfeltétel után blokkot nyitunk, azt hinné az ember, hogy a ciklusváltozó lokális lesz a ciklus 
blokkjára (a fór után következő kapcsos zárójelekkel határolt részre) nézve, de ez nem fedi a valóságot. A 
ciklusfeltételen belül deklarált ciklusváltozó lokális lesz a ciklust tartalmazó blokkra (vagyis ebben az esetben a 
teljes Main függvényre) nézve. Épp ezért a következő forráskód nem fordulna le, hiszen i már létezik: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

fór (int i = 0; i < 10; ++i) 

{ 

Console.WriteLine(i); 

} 

int i = 10; // itt a hiba, i már létezik 
Console .ReadKey(); 

} 

} 

} 


Következzen a „Meddig?"! Most azt kell megválaszolnunk, hogy a ciklusváltozó mely értéke tesz eleget a 
ciklusfeltételnek. Ebben a példában i-nek kisebbnek kell lennie tíznél, vagyis kilenc még jó, de ha ennél 
nagyobb, akkor a ciklust be kell fejezni. 

Természetesen bonyolultabb kifejezést is megadhatunk: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

fór (int i = 1; i < 10 && i != 4; ++i) 

{ 

Console.WriteLine(i); 

} 

Console .ReadKey(); 

} 

} 

} 
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Persze ennek a programnak különösebb értelme nincs, de a ciklusfeltétel érdekesebb. Addig megy a ciklus, 
amíg i kisebb tíznél és nem egyenlő néggyel. Értelemszerűen csak háromig fogja kiírni a számokat, hiszen mire a 
négyhez ér, a ciklusfeltétel már nem lesz igaz. 

Utoljára a „Hogyan?" kérdésre adjuk meg a választ, vagyis azt, hogy milyen módon változtatjuk a ciklusváltozó 
értékét. A leggyakoribb módszer a példában is látható inkrementáló (vagy dekrementáló) operátor használata, 
de itt is megadhatunk összetett kifejezést: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

fór (int i = 0; i < 10; i += 2) 

{ 

Console.WriteLine(i); 

} 

Console .ReadKey(); 

} 

} 

} 


Ebben a kódban kettesével növeljük a ciklusváltozót, vagyis a páros számokat íratjuk ki a képernyőre. 

Most már eleget tudunk ahhoz, hogy választ adjunk arra, hogy az első programunk mit csinál: nullától kilencig 
kiírja a számokat. 

A fór ciklusból tetszés szerint elhagyhatjuk a ciklusfej bármely részét - akár az egészet is, ekkor végtelen ciklust 
készíthetünk. Végtelen ciklusnak nevezzük azt a ciklust, amely soha nem ér véget. Ilyen ciklus születhet 
programozási hibából, de szándékosan is, mivel néha erre is szükségünk lesz. 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

fór (;;) 

{ 

Console.WriteLine( "Végtelen ciklus") ; 

} 

} 

} 

} 


A „program" futását a Ctrl+C billentyűkombinációval állíthatjuk le, ha parancssorból futtattuk. 

While ciklus 

Második kliensünk az elöl-tesztelős ciklus (mostantól hívjuk while-ciklusnak), amely onnan kapta a nevét, hogy 
a ciklusmag végrehajtása előtt ellenőrzi a ciklusfeltételt, ezért előfordulhat az is, hogy a ciklustörzs egyszer sem 
fut le: 
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using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

int i = 0; // ciklusváltozó deklaráció 

while (i < 10) // ciklusfeltétel: fuss amíg i kisebb, mint 10 

{ 

Console.WriteLine("i értéke: {0}", i); 

++i; // ciklusváltozó növelése 

} 

Console .ReadKey(); 

} 

} 

} 


A program ugyanazt csinálja, mint a számlálós ciklusnál bemutatott példa, viszont itt jól láthatóan elkülönülnek 
a ciklusfeltételért feleló's utasítások (kezdőérték, ciklusfeltétel, növel/csökkent). 

Működését tekintve az elöl-tesztelős ciklus hasonlít a számlálósra (mindkettő először a ciklusfeltételt ellenőrzi), 
de az előbbi sokkal rugalmasabb, mivel több lehetőségünk van a ciklusfeltétel megválasztására. 

A változó értékének kiíratásánál a Console.WriteLine egy másik verzióját használtuk, amely ún. formátum- 
sztringet kap paraméterül. Az első paraméterben a kapcsos zárójelek között megadhatjuk, hogy a további 
paraméterek közül melyiket helyettesítse be a helyére (nullától számozva). 

Do-While ciklus 

A harmadik versenyző következik, őt hátul-tesztelős ciklusnak hívják (legyen do-while ), nem nehéz kitalálni, 
hogy azért kapta ezt a nevet, mert a ciklusmag végrehajtása után ellenőrzi a ciklusfeltételt, így legalább egyszer 
biztosan lefut: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

int i = 0; 
do 
{ 

Console. WriteLine("i értéke: {0}", i); 
++i; 

} while (i < 10); 

Console. ReadKeyQ; 

} 

} 

} 
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Foreach ciklus 


Végül - de nem utolsósorban - a foreach (neki nincs külön neve) ciklus következik. Ezzel a ciklussal 
végigiterálhatunk egy tömbön vagy gyűjteményen, illetve minden olyan objektumon, ami megvalósítja az 
lEnumerable és lEnumerator interfészeket (interfészekró'l egy késó'bbi fejezet fog beszámolni, ott lesz szó erró'l 
a kettó'ró'l is). 

A példánk most nem a már megszokott „számoljunk el kilencig" lesz, helyette végigmegyünk egy string 
objektumon: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

string str = "abcdefghijklmnopqrstuvwxyz"; 

foreach (char eh in str) 

{ 

Console. Write(eh); 

} 

Console .ReadKey(); 

} 

} 

} 


A ciklusfejben felveszünk egy char típusú változót (egy string karakterekbó'l áll), utána az in kulcsszó következik, 
amivel kijelöljük azt a „listát", amelynek elemein végig szeretnénk menni. A példában használt eh változó nem 
ciklusváltozó, hanem ún. iterációs változó, amely felveszi az iterált gyűjtemény aktuális elemének értékét. 
Gyakorlatilag itt egy referenciáról van szó (legalábbis referenciatípusú elemek esetén), de a foreach ciklus nem 
módosíthatja egy gyűjtemény elemeit (le sem fordulna ebben az esetben a program). 

Ez a ciklus kétféle módban képes működni: ha a lista, amin alkalmazzuk, megvalósítja az lEnumerable és 
lEnumerator interfészeket, akkor azokat fogja használni, ha nem, akkor pedig hasonló lesz a végeredmény, 
mint egy számlálós ciklus esetében (leszámítva az iterációs változót, az mindenképpen megmarad). 

A foreach pontos működésével az interfészekró'l szóló fejezet foglalkozik majd, ahol többek között 
megvalósítunk egy osztályt, amelyen képes végigiterálni (azaz megvalósítjuk az lEnumerable és lEnumerator 
interfészeket). 

Yield 

A yield kifejezés lehetővé teszi, hogy egy ciklusból olyan osztályt generáljon a fordító, amely megvalósítja az 
lEnumerable interfészt, és ezáltal használható legyen pl. a foreach ciklussal. 

A yield használatához szükség van a System.Collections névtérre. Amennyiben ez nem szerepel a felvett 
névterek között, az IntelliSense nem nyújt segítséget, illetve fordítási hibát is okoz. 

Ha már beírtuk az lEnumerable kifejezést, és a Visual Stúdió aláhúzza pirossal (mivel nem adtuk meg a 
névteret), akkor két lehetőségünk van ennek a problémának a megoldására (valójában három, ha kézzel beírjuk 
a névteret, de hát a programozók lusták): 

1. Jobb klikk rajta, és a helyi menüből válasszuk a Resolve->Using System.Collections; sort! 

2. Ctrl + . billentyűkombináció 
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using System; 

using System.Collections; 

namespace TestApp 

{ 

eláss Program 

{ 

static public IEnumerable EnumerableMethod(int max) 

{ 

fór (int i = 0; i < max; ++i) 

{ 

yield return i; 

} 

} 

static void Main(string[] args) 

{ 

foreach (int i in EnumerableMethod(10)) 

{ 

Console.Write(i); 

} 

Console .ReadKey(); 

} 

} 

} 


A yield működési elve a következő: a legelső metódushívásnál a ciklus megtesz egy lépést, ezután „kilépünk" a 
metódusból - de annak állapotát megőrizzük, azaz a következő hívásnál nem újraindul a ciklus, hanem onnan 
folytatja, ahol legutóbb abbahagytuk. 
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Gyakorló feladatok 


Szorzótábla 

Készítsünk szorzótáblát! A program vagy a parancssori paraméterként kapott számot használja, vagy ha ilyet 
nem adtunk meg, akkor generáljon egy véletlen számot. 

Megoldás (7/Mtable.cs) 

Észrevehettük már, hogy a Main függvény rendelkezik egy paraméterrel, ami egy string típusú elemekből álló 
tömb (tömbökről a következő fejezetek adnak több tájékoztatást, most ez nem annyira lesz fontos). Ebben a 
tömbben lesznek az ún. parancssori paramétereink. 

De mi is az a parancssori paraméter? Egy nagyon egyszerű példát nézzünk meg: fordítsunk le egy C# nyelvű 
forráskódot: 


esc main.cs 


Ebben az esetben a esc a fordítóprogram neve, míg a forráskódot tartalmazó fájl neve a paraméter. Ha ezt 
vesszük alapul, akkor az args tömb egyetlen elemet tartalmaz a csc-re nézve, mégpedig a „main.cs" -t. Lássuk, 
hogy hogyan fog ez kinézni a mi programunkban (feltesszük, hogy mul.exe lesz a neve): 


mul.exe 12 


Ebben az esetben a 12 -es szorzótáblát szeretnénk látni. 

Eddig parancssoros futtatásról beszéltünk, de ehhez valójában nem kell elhagyni a Visual Studio-t. Nyissuk meg 
a Properties ablakot (jobb klikk a projekten és Properties), majd a Debug fülön a Command Line Arguments 
szövegdobozba be is írhatjuk a paramétereket. Ha több is van, szóközzel válasszuk el őket! 


Application 

Build 

Build Events 
Debug 
Resources 
Settings 

Reference Paths 


Start Options 

Command line arguments: jq 


Working directory: 

[Zl Enablethe Visual Stúdió hosting process 



A következő lépésben fejlesszük tovább a programot, hogy írja ki a paraméterként megadott szám kétszeresét! 
Ehhez még szükségünk van arra is, hogy számtípussá alakítsuk a paramétert, hiszen azt stringként kapjuk meg. 
Erre a feladatra az int.Parse metódust használjuk majd, amely számmá konvertálja a paramétereként kapott 
szöveget (persze csak akkor, ha ez lehetséges, egyébként kivételt dob). 

A forráskód most így alakul: 


using System; 

namespace TestApp 

{ 
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eláss Program 

{ 

static void Main(string[] args) 

{ 

int number = int.Parse(args[0j); 
Console.WriteLine(number * 2); 

Console .ReadKey(); 

} 

} 

} 


Mivel a tömböket mindig nullától kezdve indexeljük, ezért az első parancssori paraméter - a megadott szám - a 
„nulladik" helyen lesz. 

A program futtatásakor megkapjuk az eredményt, ami 20 lesz. Egyetlen probléma van, a program „összeomlik", 
ha nem adunk meg paramétert. 

Most módosítsuk úgy, hogy figyelmeztesse a felhasználót, hogy meg kell adnia egy számot is! Ezt úgy fogjuk 
megoldani, hogy lekérdezzük a paramétereket tartalmazó tömb hosszát, és ha ez az érték nulla, akkor kiírjuk az 
utasítást: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

if (args.Length == 0) 

{ 

Console. WriteLine( "Adjon meg egy paramétert! "); 

} 

else 

{ 

int number = int.Parse(args[0j); 

Console. WriteLine(number * 2); 

} 

Console .ReadKey(); 

} 

} 

} 


Egy kicsit szebb lesz a forráskód, ha az else ág használata helyett az if ágba teszünk egy return utasítást, amely 
visszaadja a vezérlést annak a „rendszernek", amely az őt tartalmazó metódust hívta (ez a metódus jelen 
esetben a Main, őt pedig mi - vagyis inkább az operációs rendszer - hívta, azaz a program befejezi a futását): 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

if (args.Length == 0) 

{ 

Console. WriteLine( "Adj meg egy paramétertI ") ; 

Console .ReadKey(); 

return; 
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} 

int number = int.Parse(args[0j); 
Console. WriteLine(number * 2); 


} 


} 


Console. ReadKey(); 

} 


A következő lépésben ahelyett, hogy kilépünk, ha nincs paraméter, inkább generálunk egy véletlen számot. 
Ehhez szükségünk lesz egy Random típusú objektumra. A forráskód most ilyen lesz: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

int number; 

if (args.Length == 0) 

{ 

Random r = new Random(); 

number = r.Next(100); 

} 

else 

{ 

number = int.Parse(args[0]); 

} 

Console. WriteLine(number * 2); 
Console .ReadKey(); 

} 

} 

} 


Véletlenszámot a Next metódussal generáltunk, a fenti formájában 0 és 100 között generál egy számot, de 
tetszőleges értéket is beírhatunk. 

Már nincs más dolgunk, mint megírni a feladat lényegét, a szorzótáblát: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

int number; 

if (args.Length == 0) 

{ 

Random r = new Random(); 

number = r.Next(100); 

} 

else 

{ 
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number = int.Parse(args[0j); 

} 

fór (int i = 1; i <= 10; ++i) 

{ 

Console.WriteLine("{0} x {1} = {2}", 
i, number, i * number); 

} 

Console .ReadKey(); 

} 

} 

} 


Számológép 

Készítsünk egy egyszerű számológépet! A program indításakor kérjen be két számot és egy műveleti jelet, majd 
írja ki az eredményt! 

Ezután bó'vítsük ki a programot, hogy a két számot illetve a műveleti jelet parancssori paraméterként is 
megadhassuk (ekkor nincs külön műveletválasztó menü, hanem írjuk ki rögtön az eredményt): 


main.exe 12 23 + 


(az eredmény pedig 35 lesz). 

Megoldás (7/Calculator.cs) 

Most is két részből áll a programunk, először hozzá kell jutnunk a számokhoz és az operátorhoz, majd 
elvégezzük a megfelelő műveletet és kiírjuk az eredményt. 

Ezúttal is a szükséges változók deklarációjával kezdjük a programírást, három darab kell, két numerikus (legyen 
most int) és egy karaktertípus. Ezután bekérjük a felhasználótól a szükséges adatokat, vagy pedig felhasználjuk 
a paramétereket. Ez utóbbi esetben végezzünk egy kis hibaellenőrzést, vizsgáljuk meg, hogy pontosan három 
paramétert kaptunk-e! 

A forráskód eddig így néz ki: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

int x, y; 
char op; 

if (args.Length == 0) 

{ 

Console. WriteLine( "Az első szám: "); 
x = int. Parse(Console.ReadLine()); 

Console. WriteLine("A második szám: "); 
y = int. Parse(Console.ReadLine()); 

Console. WriteLine("A mú'velet(+, *, /): "); 
op = Convert.ToChar(Console.Read()); 

} 

else 
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{ 


if 

(args.Length != 3) 

{ 

Console. WriteLine( "Túl sok/kevés paraméter! "); 
return; 

} 


else 

{ 

x = int. Parse(args[0]); 
y = int. Parse(args[1]); 
op = Convert.ToChar(args[2]); 

} 


} 


Console .ReadKey(); 

} 


} 


} 



Az operátor „megszerzéséhez" egyrészt a Console.Read függvényt használtuk (mivel csak egyetlen karakterre 
van szükség), másrészt ennek a metódusnak a visszatérési értékét - amely egy egész szám - át kellett 
konvertálnunk karaktertípussá, ehhez a Convert.ToChar metódus nyújtott segítséget. 

Most már nagyon egyszerű dolgunk van, mindössze ki kell számolnunk az eredményt. Ezt nyilván a beolvasott 
operátor alapján fogjuk megtenni, ebben a helyzetben pedig a legkézenfekvőbb, ha a switch szerkezetet 
használjuk: 


int result = 0; 

switch (op) 

{ 

case : 

result = x + y; 
break; 
case ' -' : 

result = x - y; 
break; 
case '*' : 

result = x * y; 
break; 
case '/' : 

result = x / y; 
break; 


Console.WriteLine("A művelet eredménye: {0}", result); 


Amire figyelni kell, az az, hogy a result változó kapjon kezdőértéket, ellenkező esetben ugyanis nem fordul le a 
program (uninitialized variable kezdetű hibaüzenetet kapunk). Ez azért van így, mert a változó-deklaráció és az 
utolsó sorban levő kiíratás között nem biztos, hogy megtörténik a változó-definíció. Persze mi tudjuk, hogy az 
értékadás megtörténik, a fordító viszont nem! 

Ugyan az értéktípusok bizonyos helyzetekben automatikusan nulla értéket kapnak, de ez nem minden esetben 
igaz, és lokális változók esetén épp ez a helyzet. Ezért minden olyan esetben, amikor egy lokális változó 
deklarációja és definíciója között használni akarjuk a változót, hibaüzenetet fogunk kapni. 

A fenti esetben megoldást jelenthet az is, ha bevezetünk a switch szerkezetben egy default címkét, amivel 
minden esetben megtörténik - valamilyen formában - az értékadás, ezzel pedig megnyugtatjuk a fordítót. 
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Kő - Papír - Olló 


Készítsünk kő-papír-olló játékot! Ebben az esetben is használjuk a véletlenszám-generátort. A játék folyamatos 
legyen, vagyis addig tart, amíg a felhasználó kilép (nehezítésképpen lehet egy karakter, amelyre a játék véget 
ér)! Tartsuk nyilván a játék állását, és minden forduló után írjuk ki az aktuális eredményt! 

Megoldás (7/SPS.cs) 

A programunk lényegében három részbó'l fog állni: elsó'ként megkérdezzük a felhasználótól, hogy mit 
választott, majd sorsolunk a „gépnek" is valamit, végül pedig kiértékeljük az eredményt. 

Első' dolgunk legyen, hogy deklarálunk öt darab változót, egy Random objektumot, két stringet (ezekben 
tároljuk, hogy mit választottak a „versenyzó'k"), és két byte típust (ezekben pedig az eredményeket tartjuk 
számon, itt elég lesz a byte is, mert feltesszük, hogy senki nem fog több százszor játszani egymás után)! 
Szükségünk lesz még egy logikai típusra is, ezzel fogjuk jelezni a programnak, hogy akarunk-e még játszani. 

Készítsük el a program vázát a változó-deklarációkkal, illetve a fó'ciklussal (a ciklustörzsben kérdezzünk rá, hogy 
akarunk-e még játszani): 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Random r = new Random(); 

string compChoice = 
string playerChoice = 

int compScore = 0; 
int playerScore = 0; 

bool 1 = true; 
do 
{ 

Console.WriteLine("Akarsz még játszani? i/n"); 

if (Console.ReadKey(true) .KeyChar == ’n') 

1 = false; 

} while (1); 

} 

} 

} 


A Console.ReadKey metódussal egyetlen karaktert olvasunk be a standard bemenetről, de ezt az adatot nem 
használhatjuk fel azonnal, mivel nem char típust, hanem ConsoleKeylnfo objektumot ad vissza. Ez utóbbi 
KeyChar tulajdonságával kapjuk vissza a beírt karaktert. A ReadKey most kapott egy paramétert is, amellyel azt 
jeleztük, hogy az adott karakter ne jelenjen meg a konzolon. 

Észrevehetjük, hogy az elágazásnál most elhagytuk a blokkot kijelölő kapcsos zárójeleket. Amennyiben az 
elágazás (vagy ciklus) törzse egyetlen sorból áll, akkor nem kötelező kirakni a blokkhatárolókat. 

Most kérjük be az adatokat: 


Console.WriteLine("Mit választasz? (k/p/o)"); 
switch (Console. ReadKey(true) .KeyChar) 
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{ 

case 'k' : 

playerChoice = "kő"; 
break; 
case ' p' : 

playerChoice = "papír"; 
break; 
case 'o' : 

playerChoice = "olló"; 
break; 


switch (r.Next(0, 3)) 

{ 

case 0: 

compChoice = "kő"; 
break; 
case 1: 

compChoice = "papír"; 
break; 
case 2: 

compChoice = "olló"; 
break; 


Ez a kódrészlet természetesen a ciklustörzsben a kérdés elé kerül. Az egyes lehetőségeket a k/p/o billentyűkre 
állítottuk. 

Már csak az eredmény kiértékelése van hátra: 


if ( 

(playerChoice == "kő" && compChoice == "papír") 

(playerChoice == "papír" && compChoice == "olló") 

(playerChoice == "olló" && compChoice == "kő") 

) 

{ 

Console.WriteLine("Veszítettél! Az állás:\nSzámítógép: {0}\nDátékos:{1}"., 
++compScore, playerScore); 

} 

else if (playerChoice == compChoice) 

{ 

Console.WriteLine("Döntetlen! Az állás:\nSzámítógép: {0}\n3átékos:{l}", 
compScore, playerScore); 

} 

else 

{ 

Console.WriteLine("Nyertél! Az állás:\nSzámítógép: {0}\nDátékos:{1}" , 
compScore, ++playerScore); 

} 


Érdekesebb megoldás bitműveletekkel elkészíteni a kiértékelést, ehhez egy kis segítség: jelöljük a három 
lehetőséget (k/p/o) a következőképpen: 100, 010, 001! Nyilvánvaló, hogy egy bitenkénti VAGY művelettel 
ellenőrizni tudjuk a döntetlen eredményt, mivel ekkor 100 | 100 = 100, vagyis ugyanazt kapjuk vissza. Ha az 
eredmény nem döntetlen, akkor a VAGY háromféle eredményt adhat vissza (KP, KO, OP): 110, 101 és 011, 
amelyeket pl. egy switch szerkezettel dolgozhatunk fel. 
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Szám KITALÁLÓ JÁTÉK 


Készítsünk számkitaláló játékot, amely lehetó'séget ad kiválasztani, hogy a felhasználó próbálja kitalálni a 
program által kisorsolt számot, vagy fordítva. A kitalált szám legyen 1 és 100 között. Öt próbálkozása lehet a 
játékosnak, minden tipp után írjuk ki, hogy a tippelt szám nagyobb vagy kisebb-e, mint a kitalált szám! 

Ha a gépen van a sor, akkor használjunk véletlenszám-generátort a szám létrehozására. A gépi játékos úgy 
találja ki a számot, hogy mindig felezi az intervallumot (pl. eló'ször 50-et tippel, ha a kitalált szám nagyobb, 
akkor 75 jön, és így tovább). 

A felhasználótól a játék végén kérdezzük meg, hogy akar-e ismét játszani! 

Megoldás (7/Number.cs) 

Ennek a feladatnak a legnagyobb kihívása, hogy olyan programszerkezetet rakjunk össze, amely átlátható és 
könnyen módosítható. Legyen az alapötlet az, hogy elágazásokat használunk! Nézzük meg így a program vázát: 


static void Main(string[] angs) 

{ 


// Itt kiválasztjuk, hogy ki választ számot 

if(/* A játékos választ */) 

{ 

// A számítógép megpróbálja kitalálni a számot 

} 

else// A számítógép választ 

{ 

// A játékos megpróbálja kitalálni a számot 


} 


} 


// Megkérdezzük a játékost, hogy akar-e még játszani 


Nem néz ki rosszul, de a probléma az, hogy a két feltétel blokkja nagyon el fog „hízni", emiatt pedig kevésbé 
lesz olvasható a forráskód. Ez persze nem olyan nagy baj, de ahhoz elég, hogy valami mást próbáljunk ki. 

A procedurális és alacsony szintű nyelvek az ilyen feladatokat „ugró" utasításokkal oldják meg, vagyis a 
forráskódban elhelyezett címkék között ugrálnak (tulajdonképpen a magas szintű nyelveknél is ez történik, csak 
ezt mi nem látjuk mivel, az if/switch/stb. elfedi előlünk). Ez a módszer a magas szintű nyelvek esetén nem 
igazán ajánlott (főleg, mert megvannak az eszközök az ugrálás kikerülésére), de jelenleg nem is használjuk ki 
teljesen a nyelv adta lehetőségeket, ezért most szabad „rosszalkodnunk". írjuk át a fenti vázat egy kicsit: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

START: 

Console.WriteLine("Válassz játékmódot! "); 
Console.WriteLine("l - Te gondolsz egy számra"); 
Console.WriteLine("2 - A számítógép gondol egy számra"); 

switch (Console.ReadKey(true) .KeyChar) 

{ 

case ’l’: goto PLAYER; 
case ' 2 ': goto COMPUTER; 

} 
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PLAYER: goto END; 

COMPUTER: goto END; 

END: 

Console. WriteLine("\nAkarsz még játszani? i/n"); 

switch (Console. ReadKey(true).KeyChar) 

{ 

case 'i' : goto START; 
case 'n' : break; 

} 

} 

} 

} 


Közben ki is egészítettük a kódot egy kicsit, lehet vele kísérletezni, amíg el nem készítjük a lényeget. Jól látható, 
hogy a címkékkel kellemesen olvashatóvá és érthetővé vált a kód (persze ennél nagyobb terjedelmű forrásnál 
már problémásabb lehet). 

Már elkészítettük a programrészt, amely megkérdezi a játékost, hogy szeretne-e még játszani. Egy apró hibája 
van, mégpedig az, hogy ha i vagy n helyett más billentyűt nyomunk le, akkor a program véget ér. Ezt könnyen 
kijavíthatjuk, ha egy kicsit gondolkodunk. Nyilván a default címkét kell használni, és ott egy ugró utasítással a 
vezérlést a megfelelő helyre tenni: 


END: 

Console.WriteLine("\nAkarsz még játszani? i/n"); 

switch (Console.ReadKey(true) .KeyChar) 

{ 

case 'i' : goto START; 
case 'n' : break; 
default: goto END; 

} 


Most következik a program lényege: a játék elkészítése. Elsőként azt a szituációt implementáljuk, amikor a 
játékos próbálja kitalálni a számot, mivel ez az egyszerűbb. 

Szükségünk lesz természetesen változókra is, de érdemes átgondolni, hogy úgy vegyük fel őket, hogy mindkét 
programrész használhassa őket. Ami biztosan mindkét esetben kell, az a véletlenszám-generátor, valamint két 
int típusú változó az egyikben a játékos és a számítógép tippjeit tároljuk, a másik pedig a ciklusváltozó lesz, neki 
adjunk azonnal nulla értéket. Ezt a kettőt deklaráljuk egyelőre, rögtön a START címke előtt! Készítsük is el a 
programot, nem lesz nehéz dolgunk, mindössze egy ciklusra lesz szükségünk: 


COMPUTER: 

int number = r.Next(100); 
i = 0; 

while(i < 5) 

{ 

Console .WriteLine( "\nA tipped: "); 
x = int.Parse(Console.ReadLine()); 

if(x < number) 

{ 

Console. WriteLine( "A szám ennél nagyobb!"); 

} 

else if(x > number) 

{ 

Console. WriteLine( "A szám ennél kisebb!"); 

} 

else 
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{ 

Console.WriteLine(" Nyertél! "); 
goto END; 

} 

++ij 


Console. WriteLine( "XnVesztettél., a szám {0} volt."., number); 
goto END; 


Ennek megértése nem okozhat gondot, léphetünk a következő állomásra, ami viszont kicsit nehezebb lesz. 
Ahhoz, hogy megfelelő stratégiát készítsünk a számítógép számára, magunknak is tisztában kell lennünk azzal, 
hogy hogyan lehet megnyerni ezt a játékot. A legáltalánosabb módszer, hogy mindig felezzük az intervallumot, 
így az utolsó tippre már elég szűk lesz az a számhalmaz, amiből választhatunk (persze így egy kicsit 
szerencsejáték is lesz). 

Nézzünk meg egy példát: a gondolt szám legyen a 87, és tudjuk, hogy a szám egy és száz között van! Az első 
tippünk 50 lesz, amire természetesen azt a választ kapjuk, hogy a szám ennél nagyobb. Már csak 50 lehetséges 
szám maradt, ismét felezünk, a következő tippünk így a 75 lesz. Ismét azt kapjuk vissza, hogy ez nem elég. Ismét 
felezünk, méghozzá maradék nélkül, vagyis tizenkettőt adunk hozzá a hetvenöthöz, és így ki is találtuk a gondolt 
számot. 

Most már könnyen fel tudjuk írni, hogy mit kell tennie a számítógépnek: az első négy kísérletnél felezzük az 
intervallumot, az utolsó körben pedig tippelünk. Nézzük a kész kódot: 


PLAYER: 

Console.WriteLine("Gondolj egy számra! (1 - 100)"); 

Console .ReadLine(); 

x = 50; 
int min = 0; 
int max = 100; 
while (i < 5) 

{ 

Console. WriteLine( "A számítógép szerint a szám {0}"., x); 
Console. WriteLine( "Szerinted? (k/n/e) ") ; 

switch (Console. ReadKey(true) .KeyChar) 

{ 

case 'k' : 

if (i == 3) 

x = r.Next(min, x); 

else 

{ 

max = x; 

x -= (max - min) / 2; 

} 

break; 
case ' n' : 

if (i == 3) 

x = r.Next(x + 1, max); 

else 

{ 

min = x; 

x += (max - min) / 2; 

} 

break; 
case ' e' : 

Console. WriteLine("A számítógép nyert!"); 
goto END; 

} 

++i; 
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} 

Console.WriteLine("A számítógép nem tudta kitalálni a számot."); 
goto END; 


A min illetve max változókkal tartjuk számon az intervallum alsó, illetve felső határát. Az x változóban tároljuk 
az aktuális tippet, neki meg is adtuk a kezdőértéket. 

Egy példán keresztül nézzük meg, hogy hogyan működik a kódunk! Legyen a gondolt szám ismét 87! A 
számítógép első tippje 50, mi erre azt mondjuk, hogy a szám ennél nagyobb, ezért a switch 'n' ága fog 
beindulni. Az intervallum alsó határa ezután x (vagyis 50) lesz, mivel tudjuk, hogy a szám ennél biztosan 
nagyobb. A felső határ nyilván nem változik, már csak az új x-et kell kiszámolni, vagyis hozzá kell adni a felső és 
alsó határok különbségének a felét: (100 - 50) / 2 = 25 (ellenkező esetben pedig nyilván le kellene vonni 
ugyanezt). 

Amiről még nem beszéltünk, az az a feltétel, amelyben x egyenlőségét vizsgáljuk hárommal (vagyis azt akarjuk 
tudni, hogy eljött-e az utolsó tipp ideje). Ez az elágazás fogja visszaadni az utolsó tippet a véletlenszám- 
generátorral a megfelelően leszűkített intervallumban. 


67 



Típuskonverziók 


Azt már megtanultuk, hogy az egyes típusok másként jelennek meg a memóriában, azonban gyakran kerülünk 
olyan helyzetbe, hogy egy adott típusnak úgy kellene viselkednie, mint egy másiknak. Ilyen helyzetekben 
típuskonverziót (castolást) kell elvégeznünk. 

Kétféleképpen konvertálhatunk: implicit és explicit módon. Az előbbi esetben nem kell semmit tennünk, a 
fordító kérés nélkül elvégzi helyettünk. Implicit konverzió általában „hasonló" típusokon működik, szinte 
minden esetben a szűkebb típusról a tágabbra: 


int x = 10; 

long y = x; // y == 10, implicit konverzió 


Ebben az esetben a long és int mindketten egész, numerikus típusok, és mivel a long tágabb (az int 32 bites, 
míg a long 64 bites egész szám), ezért a konverzió gond nélkül végbemegy. Egy implicit konverzió minden 
esetben sikeres, és nem jár adatvesztéssel. 

Egy explicit konverzió nem feltétlenül fog működni, és ha mégis, akkor adatvesztés is felléphet. Vegyük a 
következő példát: 


int x = 300; 

byte y = (byte)x; // explicit konverzió, y == ?? 


A byte szűkebb típus, mint az int (8 illetve 32 bitesek), ezért explicit konverziót hajtottunk végre, ezt a változó 
előtti zárójelbe írt típussal jelöltük. Ha lehetséges a konverzió, akkor végbemegy, egyébként a fordító 
figyelmeztetni fog. 

Vajon mennyi most az y változó értéke? A válasz elsőre meglepő lehet: 44. A magyarázat: a 300 egy kilenc biten 
felírható szám (100101100), persze az int kapacitása ennél nagyobb, de most csak a hasznos részre van 
szükség. A byte viszont (ahogy a nevében is benne van) egy nyolcbites értéket tárolhat (vagyis a maximum 
értéke 255 lehet), ezért a 300-nak csak az első 8 bitjét (00101100) adhatjuk át y-nak, ami pont 44. 


Ellenőrzött konverziók 

A programfejlesztés alatt hasznos lehet tudnunk, hogy minden konverzió gond nélkül lezajlott-e vagy sem. 
Ennek ellenőrzésére ún. ellenőrzött konverziót fogunk használni, amely kivételt dob (erről hamarosan), ha a 
forrás nem fér el a célváltozóban: 


checked 

{ 

int x = 300; 
byte y = (byte)x; 

} 


Ez a kifejezés kivételt (System.OverflowException) fog dobni, ha elindítjuk a lefordított programot, hibaüzenet 
fogad majd. Figyeljünk arra, hogy ilyen esetekben csak a blokkon belül deklarált, statikus és tagváltozókat 
vizsgálhatjuk. 

Előfordul, hogy csak egy-egy konverziót szeretnénk vizsgálni, amihez nincs szükség egy egész blokkra: 


int x = 300; 

byte y = checked( (byte)x) ; 


Az ellenőrzés kikapcsolását is megtehetjük az unchecked használatával: 


int x = 300; 

byte y = unchecked( (byte)x) ; 
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Az ajánlás szerint ellenőrzött konverziókat csak a fejlesztés ideje alatt (tesztelésre) használjunk, mivel némi 
teljesítményvesztéssel jár! 


IS ÉS AS 


Az is operátort futásidejű típus-lekérdezésre használjuk: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

int x = 10; 

if (x is int) // ha x egy int 

{ 

Console.WriteLine("x típusa int"); 

} 

Console .ReadKey(); 

} 

} 

} 


Ez a program lefordul, de figyelmeztetést kapunk, mivel a fordító felismeri, hogy a feltétel mindig igaz lesz. 
Ennek az operátornak a leggyakoribb felhasználási területe az interfész-megvalósitás lekérdezése (erről 
később). 

Párja, az as az ellenőrzés mellett egy explicit típuskonverziót is végrehajt. Ezzel az operátorral csakis referencia¬ 
típusra konvertálhatunk, értéktípusra nem (ekkor le sem fordul a program). 

Az as operátort csakis akkor használjuk típusellenőrzésre, ha egyúttal konverziót is szeretnénk végezni, pusztán 
vizsgálat céljából az is operátort kell alkalmazni. Nézzünk egy példát: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

object a = "123"; 
object b = "Hello"; 
object c = 10; 

string aa = a as string; 

Console. WriteLine(aa == null ? "NULL" : aa); // 123 
string bb = b as string; 

Console. WriteLine(bb == null ? "NULL" : bb); // Hello 
string cc = c as string; 

Console. WriteLine(cc == null ? "NULL" : cc); // NULL 
Console .ReadKey(); 

} 
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Amennyiben ez a konverzió nem hajtható végre, a célváltozóhoz null érték rendeló'dik (ezért is van a referencia¬ 
típusokra korlátozva ez az operátor). 


Karakterkonverziók 

A char típust implicit módon tudjuk numerikus típusra konvertálni, ekkor a karakter Unicode értékét kapjuk 
vissza: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

fór (char eh = 'a'; eh <= ’z’; ++ch) 

{ 

Console.WriteLine( (int) eh); 

} 

Console.ReadKeyQ; 

} 

} 

} 


Erre a kimeneten a következő számok jelennek meg: 97, 98, 99,100,... 

A kis 'a' betű hexadecimális Unicode száma 0061h, ami a 97 decimális számnak felel meg, tehát a konverzió a 
tízes számrendszerbeli értéket adja vissza. 


Az Unicode nemzetközi karakter kódolási szabvány, amely a világ írásrendszereinek nagy részét tartalmazza 
(jelenleg több mint 110000 karaktert tartalmaz). 
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Tömbök 


Gyakran van szükségünk arra, hogy több azonos típusú objektumot tároljunk el, ilyenkor kényelmetlen lenne 
mindegyiknek külön változót foglalnunk (képzeljünk el 30 darab int típusú változót, még leírni is egy 
örökkévalóság lenne). De ezt nem is kell megtennünk, hiszen rendelkezésünkre áll a tömb adatszerkezet. 

A tömb meghatározott számú, azonos típusú elemek halmaza. Minden elemre egyértelműen mutat egy index 
(egész szám). A tömbök referenciatípusok. A C# mindig folytonos memóriablokkokban helyezi el egy tömb 
elemeit. Tömböt a következőképpen deklarálhatunk: 


int[] arnay = new int[10]; 


Ez a tömb tíz darab int típusú elem tárolására alkalmas. A tömb deklarációja után az egyes indexeken lévő 
elemek automatikusan a megfelelő null értékre inicializálódnak (ebben az esetben 10 darab nullát fog 
tartalmazni a tömbünk). Ez a szabály referenciatipusoknál kissé máshogy működik, mivel ekkor a tömbelemek 
null -ra inicializálódnak. Ez nagy különbség, mivel értéktípusok esetében szimpla nullát kapnánk vissza az 
általunk nem beállított indexre hivatkozva (vagyis ez egy teljesen szabályos művelet), míg referenciatípusoknál 
ugyanez NullReferenceException típusú kivételt fog generálni. 

Az egyes elemekre az indexelő operátorral (szögletes zárójelek: [ ]) és az elem indexével (sorszámával) 
hivatkozunk. A számozás mindig nullától kezdődik, így a legutolsó elem indexe: az elemek száma mínusz egy. A 
következő példában feltöltünk egy tömböt véletlen számokkal és kiíratjuk a tartalmát: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

int[] array = new int[10]; 

Random r = new Random(); 

fór (int i = 0; i < array.Length; ++i) 

{ 

array[i] = r.Next(0j 100); 

} 

foreach (int item in array) 

{ 

Console.WriteLine(item); 

} 

Console .ReadKey(); 

} 

} 

} 


A példában a ciklusfeltétel megadásakor a tömb Length nevű tulajdonságát használtuk, amely visszaadja a 
tömb hosszát. Látható az indexelő-operátor használata is, az array[i] a tömb i-edik elemét jelenti. Az 
indexeléssel vigyázni kell, ugyanis a fordító nem ellenőrzi fordítási időben az indexek helyességét, viszont 
helytelen indexelés esetén futás időben IndexOutOfRangeException kivételt fog dobni a program. 

A tömb adott elemét az értékadással egy időben is kiírhattuk volna, a példában csak szemléltetés céljából 
használtunk kétféle ciklust. 

Egy tömböt akár a deklaráció pillanatában is feltölthetünk a nekünk megfelelő értékekkel: 


char[] charArray = new char[] { 'b' , ’d', 'a', ’c' }; 
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Egy tömb által tárolható elemek számát a deklarációval azonnal meghatározzuk, ezen a későbbiekben nem 
lehet változtatni. Dinamikusan bővíthető adatszerkezetekről a Gyűjtemények című fejezet szól. 

Minden tömb a System.Array osztályból származik, ezért néhány hasznos művelet azonnal rendelkezésünkre 
áll (pl. rendezhetünk egy tömböt a Sort metódussal): 


chararray.Sort(); // tömb rendezése 


Többdimenziós tömbök 


Eddig az ún. egydimenziós tömböt (vektort) használtuk. Lehetőségünk van azonban többdimenziós tömbök 
létrehozására is, ekkor nem egy indexszel hivatkozunk egy elemre, hanem annyival, ahány dimenziós a tömb. 
Vegyük például a matematikából már ismert mátrixot: 

12, 23, 2 
A = [ 13, 67, 52 ] 

45, 55, 1 

Ez egy kétdimenziós tömbnek (mátrix) felel meg, az egyes elemekre két indexszel hivatkozunk, első helyen a sor 
áll és utána az oszlop. így a 45 indexe: [2, 0] (ne feledjük, még mindig nullától indexelünk). 

Multidimenziós tömböt a következő módon hozunk létre C# nyelven: 


int[,] mátrix = new int[3, 3]; 


Ez itt egy 3x3-as mátrix, olyan, mint a fent látható. Itt is összeköthetjük az elemek megadását a deklarációval, 
bár egy kicsit trükkösebb a dolog: 


int[ j] 

mátrix = 

new int[ j] 

{ 





{12, 

23, 

2}, 


{13, 

67, 

52}, 


{45, 

55, 

1} 

}; 





Az elemszám most is meghatározott, nem változtatható. 

Nyilván nem akarjuk mindig kézzel feltölteni a tömböket, viszont ezúttal nem olyan egyszerű a dolgunk, hiszen 
egy ciklus biztosan nem lesz elég ehhez, vagyis gondolkodnunk kell: az index első tagja a sort, a második az 
oszlopot adja meg, pontosabban az adott sorban elfoglalt indexét. Ez alapján pedig jó ötletnek tűnik, ha 
egyszerre csak egy dologgal foglalkozunk, azaz szépen végig kell valahogyan mennünk minden soron egyesével. 
Erre a megoldást az ún. egymásba ágyazott ciklusok jelentik: a külső ciklus a sorokon megy át, a belső pedig a 
sorok elemein: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

int[j] mátrix = new int[3, 3]j 

Random r = new Random(); 

fór (int i = 0; i < mátrix.GetLength(0); ++i) // sorok 
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{ 

fór (int j = 0; j < mátrix.GetLength(l); ++j) // oszlopok 

{ 

matrix[i, j] = r.Next(0, 100); 

} 

} 

Console .ReadKey(); 

} 

} 

} 


Most nem írjuk ki a számokat, ez már nem okozhat gondot az olvasónak. A tömbök GetLength metódusa a 
paraméterként megadott dimenzió hosszát adja vissza (nullától számozva), tehát a példában az első' esetben a 
sor, a másodikban az oszlop hosszát adjuk meg a ciklusfeltételben. 

A többdimenziós tömbök egy variánsa az ún. egyenetlen (jagged) tömb. Ekkor legalább egy dimenzió hosszát 
meg kell adnunk, ez konstans marad, viszont a belső' tömbök hossza tetszés szerint megadható: 


int [][] jarray = new int[3][]; 


Készítettünk egy három sorral rendelkező tömböt, azonban a sorok hosszát (az egyes sorok maguk is önálló 
vektorok) ráérünk később megadni, és nem kell ugyanolyan hosszúnak lenniük. 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

±rvt [] [] jarray = new int[3][]; 

Random r = new Random(); 

fór (int i = 0; i < 3; ++i) 

{ 

jarray[i] = new int[r.Next(l, 5)]; 
fór (int j = 0; j < jarray[i].Length; ++j) 
{ 

jarray[i][j] = i + j; 

Console. Write("{0}, ", jarray[i][j]); 

} 

Console.WriteLine( ); 

} 

Console .ReadKey(); 

} 

} 

} 


Véletlenszám-generátorral adtuk meg a belső tömbök hosszát, persze értelmes kereteken belül. A belső 
ciklusban jól látható, hogy a tömb elemei valóban tömbök, hiszen használtuk a Length tulajdonságot (persze a 
hagyományos többdimenziós tömbök esetében is ez a helyzet, de ott nem lenne értelme külön elérhetővé 
tenni az egyes sorokat). 

Az inicializálás a következőképpen alakul ebben az esetben: 


73 





int [][] jarray = 

new 

int [][] 

{ 




new 

int [ ]{ 


2, 3, 4j 5 }, 

new 

int []{ 


2, 3 }, 

new 

}; 

int []{ 

i > 
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Stringek 


A C# beépített karaktertípusa (char) egy Unicode karaktert képes tárolni két byte-on. A szintén beépített string 
típus ilyen karakterekből áll (tehát az egyes betűket char példányként kezelhetjük). 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

string s = "ezegystring"; 
Console.WriteLine(s); 

Console .ReadKey(); 

} 

} 

} 


A látszat ellenére a string referenciatípus, viszont nem kötelező használnunk a new operátort a deklarációjakor. 
Egy string egyes karaktereire az indexelő operátorral hivatkozhatunk (vagyis minden stringet kezelhetünk 
tömbként is): 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

string s = "ezegystring"; 
Console. WriteLine(s[0]); // e 

Console .ReadKey(); 

} 

} 

} 


Ekkor a visszaadott objektum típusa char lesz. A foreach ciklussal indexelő operátor nélkül is végigiterálhatunk 
a karaktersorozaton: 


foreach (char eh in s) 

{ 

Console. WriteLine(eh); 

} 


Az indexelő operátort nemcsak változókon, de „nyers" szövegen is alkalmazhatjuk: 


Console. WriteLine("ezegystring"[4]); // y 


Ilyenkor egy „névtelen" változót készít a fordító, és azt használja. Nagyon fontos tudni, hogy mikor egy létező 
string objektumnak új értéket adunk, akkor nem az eredeti példány módosul, hanem egy teljesen új objektum 
keletkezik a memóriában (vagyis a string ún. immutable - megváltoztathatatlan - típus). Ez a viselkedés főleg 
akkor okozhat (teljesítmény)problémát, ha sokszor van szükségünk ilyen műveletekre. 
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Metódusok 


A .NET számos hasznos metódust biztosít a stringek hatékony kezeléséhez. Most megvizsgálunk néhányat, de 
tudni kell, hogy a van, amelyiknek számos változata is lehet, most a leggyakrabban használtakat nézzük meg: 

Összehasonlítás: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

string a = "egyik"; 
string b = "másik"; 

int x = String. Compare(aj b); 

if (x == 0) 

{ 

Console.WriteLine("A két string egyenlő"); 

} 

else if (x < 0) 

{ 

Console.WriteLine("Az 'a' a kisebb"); 

} 

else 

{ 

Console.WriteLine("A 'b' a kisebb"); 

} 

Console .ReadKey(); 

} 

} 

} 


A String.Compare metódus nullát ad vissza, ha a két string egyenlő, és nullánál kisebbet/nagyobbat, ha nem 
(pontosabban, ha lexikografikusan - lényegében ábécésorrend szerint - kisebb/nagyobb). 

Keresés: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

string s = "verylonglongstring"; 

char[] chs = new char[] { 'y' , 'z' , ’o' }; 

Console. WriteLine(s.IndexOf( 'r ')); // 2 
Console. WriteLine(s.IndexOfAny(chs)); // 3 
Console. WriteLine(s.LastIndexOf( 'n' )); // 16 
Console. WriteLine(s.LastlndexOfAny(chs)); // 9 
Console. WriteLine(s.Contains("long")); // true 
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Console .ReadKey(); 


} 


} 


} 


Az IndexOf és LastlndexOf metódusok egy karakter vagy karaktersorozat első illetve utolsó előfordulási indexét 
(utóbbi esetén a kezdőindexet) adják vissza. Ha nincs találat, akkor a visszaadott érték -1 lesz. A két metódus 
Any-re végződő változata egy karaktertömböt fogad paramétereként, és az abban található összes karaktert 
próbálja megtalálni. A Contains igaz értékkel tér vissza, ha a paramétereként megadott karakter(sorozat) benne 
van a stringben. 

Módosítás: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

string s = "smallstring"; 

char[] chs = new char[] { 's', 'g' }; 

Console. WriteLine(s.Replace( 's' , ’l')); // lmallltring 
Console. WriteLine(s.Trim(chs)); // mallstrin 
Console. WriteLine(s.lnsert(0j "one")); // onesmallstring 
Console. WriteLine(s.Remove(0j 2)); // allstring 
Console. WriteLine(s.Substring(0j 3)); // sma 
Console. WriteLine(s.ToUpper()); // SMALLSTRING 
Console. WriteLine(s.ToLower()); // smallstring 

Console .ReadKey(); 

} 

} 

} 


A Replace metódus az első paraméterének megfelelő karaktereket lecseréli a második paraméterre. ATrim a 
string elején és végén lévő karaktereket vágja le, a Substring pedig kivág egy karaktersorozatot, paraméterei a 
kezdő és végindexek (van egyparaméteres változata is, ekkor csak a kezdőindexet adjuk meg és a végéig megy). 
Az Insert/Remove metódusok hozzáadnak, illetve elvesznek a stringből (a megadott indexeken). Végül a 
ToLower és Tollpper metódusok kis- illetve nagybetűssé alakítják az eredeti stringet. 

Fontos megjegyezni, hogy ezek a metódusok soha nem az eredeti stringen végzik a módosításokat, hanem egy 
új példányt hoznak létre, és azt adják vissza. 


StringBuilder 

Azt már tudjuk, hogy amikor módosítunk egy stringet, akkor automatikusan egy új példány jön létre a 
memóriában, ez pedig nem feltétlenül „olcsó" művelet. Ha sokszor (legalább 10+ alkalom) van szükségünk erre, 
akkor használjuk inkább a StringBuilder típust, ez automatikusan lefoglal egy nagyobb darab memóriát, és ha 
ez sem elég, akkor allokál egy megfelelő méretű területet, és átmásolja magát oda. A StringBuilder a 
System.Text névtérben található. Példa a StringBuilder használatára: 


using System; 
using System.Text; 

namespace TestApp 

{ 
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eláss Program 

{ 

static void Main(string[] args) 

{ 

StringBuilder sb = new StringBuilder(50) ; 

fór (char eh = 'a'; eh <= ’z'; ++ch) 

{ 

sb.Append(ch); 

} 

Console.WriteLine(sb); 

Console .ReadKey(); 

} 

} 

} 


A StringBuilder fenti konstruktora (van több is) helyet foglal ötven karakter számára (létezik alapértelmezett 
konstruktora is, ekkor tizenhat karakternek foglal helyet). Az Append metódussal tudunk karaktereket (vagy 
egész stringeket) hozzáfűzni. 


Reguláris kifejezések 

Reguláris kifejezések segítségével vizsgálhatjuk, hogy egy karaktersorozat megfelel-e egy adott mintának. 
Nézzünk is egy példát: készítsünk olyan reguláris kifejezést, amely természetes számokra illik! A példában a 
nullát nem soroljuk a természetes számok közé, vagyis a minta a következő lesz: az első számjegy egy és kilenc 
közötti lesz, ezután pedig bármennyi nulla és kilenc közötti számjegy jöhet. A forráskód: 


using System; 

using System.Text.RegularExpressions; 


namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

Regex pattern = new Regex(" A [l-9][0-9]*"); 


string sl = "012345"; 

string s2 = "112345"; 

string s3 = "2"; 

Console. WriteLine( "{0} 
"természetes szám" 

Console. WriteLine( "{0} 
"természetes szám" 

Console. WriteLine( "{0} 
"természetes szám" 

Console .ReadKey(); 

} 

} 

} 


{1}", sl, (pattern.IsMatch(sl) 
"nem természetes szám")); 

{1}", s2, (pattern.IsMatch(s2) 
"nem természetes szám")); 

{1}", s3, (pattern.IsMatch(s3) 
"nem természetes szám")); 


A reguláris kifejezést egy Regex példánynak adjuk át, lássuk, hogy hogyan épül fel: 
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A : ezzel a karakterrel (Alt Gr + 3) megmondjuk, hogy a mintaillesztést a string elejétől kell kezdeni. 

[1-9]: a string elején egy darab numerikus karakter áll - kivéve a nullát. 

[0-9]*: a csillag(*) nulla vagy több előfordulást jelent, vagyis az első számjegy után nulla vagy több nulla és 
kilenc közötti szám állhat. 

A programunk a következő kimenetet produkálja: 


012345 : nem természetes szám 
112345 : természetes szám 
2 : természetes szám 


A következő példánk egy kicsit bonyolultabb lesz, a reguláris kifejezés pedig már-már ijesztő. Képzeljük el, hogy 
a világon uniformizálják a telefonszámokat, a következő módon: minden szám az ország előhívójával kezdődik, 
amelyet egy '+' jel előz meg, az előhívószám két vagy három számjegyből áll, az első szám nem lehet nulla. 
Ezután egy szóköz jön, amelyet a körzetszám követ, ami szintén két vagy három számjegy, az első helyen itt 
sem állhat nulla. Végül következik a telefonszám, ami a körzetszámot szóközzel elválasztva követi. Minden 
telefonszám három darab három számjegyből álló blokkból áll, ezeket kötőjel választja el. Egy példa: 


+36 30 123-456-789 


Lássuk a forráskódot: 


string s = @" A (\+)[l-9][0-9]{lj2}\s[l-9][0-9]{lj2}\s(\d{3}(-)){2}\d{3}$"; 

Regex pattern = new Regex(s); 

string sl = "+36 30 661-345-612"; 
string s2 = "+3630 661-567-233"; 

String s3 = "+56 30 667-876-987-456"; 

Console.WriteLine(pattern.IsMatch(sl)); // true 
Console.WriteLine(pattern.IsMatch(s2)); // false 
Console.WriteLine(pattern.IsMatch(s3)); // false 


A reguláris kifejezés elé kötelezően oda kell tennünk a @ jelet, mivel speciális karaktereket is tartalmaz (erre a 
fordító is figyelmeztet). A kifejezésünk két részből áll: 

A (\+)[l-9][0-9]{l,2}\s: ez a minta lesz az első két helyen és ő hivatott az előhívót illetve a körzetszámot 
ellenőrizni: a már ismert A -vel az illesztést a karaktersor elejétől kezdjük, az ezt követő (\+) pedig megmondja, 
hogy az első helyen egy'+' jel van (ez persze nem lesz ott a körzetszám előtt). A'+' elé '\ -t kell tennünk, mivel 
ennek a jelnek önálló jelentése is van reguláris kifejezésben. A zárójelek közé „nyers" karaktereket (is) írhatunk. 
Ezután ismerős következik: az [1-9][0-9] -et már nem okozhat gondot megérteni, az utána következő {1,2} -t 
már inkább. Ezzel azt közöltük, hogy az előtte lévő meghatározás ([0-9]) legalább egy, legfeljebb két alkalommal 
szerepel egymás után. Végül a \s egy szóközt jelöl. 

(\d{3}(-)){2}\d{3}$: ez a kifejezés a kötőjellel elválasztott számblokkokat jelöli. A végén lévő $ jel jelzi, hogy a 
karaktersorozat végéig kell illesztenie, vagyis az egészet ellenőrizze (máskülönben a 345-345-345-456 sorozat 
érvényes lenne, hiszen benne van az, amit kerestünk). 

Haladjunk továbbra is a végéről: a {3}—ról már tudjuk, hogy azt jelenti: az előtte lévő kifejezésnek pontosan 
háromszor kell szerepelnie, ez jelen esetben azt jelenti, hogy a minta végén három számjegy áll, amelyet a \d- 
vel (d mint digit) jelölünk. 

A \d előtt szereplő {2} az egész zárójelben lévő kifejezésre vonatkozik, ahol megmondtuk, hogy három számjegy 
után egy kötőjel következik. 
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A .NET reguláris kifejezései meglepően sokrétűek, rengeteg lehetőségünk van, a fenti két példa csak ízelítő volt. 
További információt találhatunk az MSDN megfelelő oldalán: 

http://msdn.microsoft.com/en-us/library/az24scfc(v=VS.90).aspx 
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Gyakorló feladatok II. 


Minimum- és maximumkeresés 

Keressük ki egy tömb legnagyobb, illetve legkisebb elemét és ezek indexeit (ha több ilyen elem van, akkor elég 
az első előfordulás)! 

Megoldás (11/MinMax.cs) 

A mininum/maximum-keresés a legalapvetőbb algoritmusok egyike. Az alapelv rendkívül egyszerű, 
végigmegyünk a tömb elemein, és minden elemet összehasonlítunk az aktuális legkisebbel/legnagyobbal. 
Nézzük is meg a forráskódot (csak a lényeg szerepel itt, a tömb feltöltése nem okozhat gondot): 


int min = 1000; 
int max = -1; 
int minldx = 0; 
int maxldx = 0; 

fór (int i = 0; i < 30; ++i) 

{ 

if (array[i] < min) 

{ 

min = array[i]; 
minldx = i; 

} 

if (array[i] > max) 

{ 

max = array[i]; 
maxldx = i; 

} 

} 


A min és max változóknak kezdőértéket is adtunk, ezeket úgy kell megválasztani, hogy ezek biztosan kisebbek 
illetve nagyobbak legyenek, mint a tömb elemei (feltesszük, hogy nullánál kisebb és ezernél nagyobb szám 
nincs a tömbben). 


Értelemszerűen, mivel minden elemet kötelezően meg kell vizsgálnunk, ez az algoritmus nem túl gyors nagy 
elemszám esetén, viszont nagyon jól működik párhuzamos környezetben - a tömb egyes részeit külön 
feldolgozóegység kapja meg. 


Szigetek 

Egy szigetcsoport fölött elrepülve bizonyos időközönként megnéztük, hogy épp hol vagyunk. Ha sziget 
(szárazföld) fölött, akkor leírtunk egy egyest, ha tenger fölött, akkor nullát. 

A programunk ezt az adatot dolgozza föl, amelyet vagy a billentyűzetről, vagy - ha van - a parancssori 
paraméterből kap meg. A feladatok: 

• Adjuk meg a leghosszabb egybefüggő szárazföld hosszát! 

• Adjuk meg, hogy hány szigetet találtunk! 
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Megoldás (11/Islands.cs) 

A megoldásban csak az adatok feldolgozását nézzük meg, a beolvasásuk nem okozhat mostanra gondot. A 
szigeteken végzett méréseket a data nevű, string típusú változóban tároltuk el. 

A két feladatot egyszerre fogjuk megoldani, mivel a programunk a következő elven alapul: a data stringen 
fogunk keresztülmenni egy ciklus segítségével. Ha a string adott indexén egyest találunk, akkor elindítunk egy 
másik ciklust, amely attól az indextől megy egészen addig, amíg nullához nem ér. Ekkor egyrészt megnöveljük 
eggyel a szigetek számát tároló változót, másrészt tudni fogjuk, hogy milyen hosszú volt a sziget, és 
összehasonlíthatjuk az eddigi eredményekkel. Nézzük is meg a forráskódot: 


int islandCount = 0; 
int maxIslandLength = 0; 
int i = 0; 

while (i < data.Length) 

{ 

if (data[i] == '1') 

{ 

++islandCount; 
int j = i; 
int tmp = 0; 

while (j < data.Length && data[j] == '1') 

{ 

++j; 

++tmp; 

} 

i = j; 

if (tmp > maxIslandLength) { maxIslandLength = tmp; } 

} 

else 

{ 

++i; 

} 

} 


A kódban két érdekes dolog is van. Az első a belső ciklus feltétele: ellenőrizzük, hogy még a szigetet mérjük és 
azt is, hogy nem értünk-e a string végére. Ami fontos, az a feltételek sorrendje: mivel tudjuk, hogy a feltételek 
kiértékelése balról jobbra halad, ezért először azt kell vizsgálnunk, hogy helyes indexet használunk-e, ellenkező 
esetben ugyanis kivételt kapnánk (hiszen ha a string vége után vagyunk, ott már nincs semmi). 

A másik érdekesség a két ciklusváltozó. Amikor befejezzük a belső ciklust, akkor a külső ciklusváltozót új 
pozícióba kell helyeznünk, méghozzá oda, ahol a belső ciklus abbahagyta a vizsgálatot. 


Átlaghőmérséklet 

Az év minden napján megmértük az átlaghőmérsékletet, az eredményeket pedig egy mátrixban tároltuk (az 
egyszerűség kedvéért tegyük fel, hogy minden hónap harminc napos, az eredményeket pedig véletlenszám- 
generátorral (ésszerű kereteken belül) sorsoljuk ki). 

• Keressük meg az év legmelegebb és leghidegebb napját! 

• Adjuk meg az év legmelegebb és leghidegebb hónapját! 

• Volt-e egymást követő öt nap (egy hónapon belül), amikor mínusz fokot mértünk? 
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Megoldás (11/Temperature.cs) 

Ehhez a feladathoz nem tartozik írásos megoldás, tulajdonképpen egy minimum- és maximum-kiválasztásról 
van szó, csak éppen kétdimenziós tömbben (viszont a jegyzethez csatolva van egy lehetséges megoldás). 


Buborékrendezés 


Valósítsuk meg egy tömbön a buborékrendezést! 

Megoldás (11/BubbleSort.cs) 

A buborékos rendezés egy rendezési algoritmus, amelynek alapelve, hogy a kisebb elemek - buborék módjára - 
felszivárognak, míg a nagyobb elemek lesüllyednek. Ennek az algoritmusnak többféle implementációja is 
létezik, mi most két változatát is megvizsgáljuk. Az első' így néz ki: 


fór (int i = 0; i < array.Length - 1; ++i) 

{ 

fór (int j = array.Length - 1; j > i; --j) 

{ 

if (array[j - 1] > array[j]) 

{ 

int tmp = array[j]; 
array[j] = array[j - l]j 
array[j - 1] = tmp; 

} 

} 

} 


Kezdjük a belső' ciklussal! Ez a tömb végéről fog visszafelé menni és cserélgeti az elemeket, hogy a legkisebbet 
vigye tovább magával. Legyen pl. a tömb utolsó néhány eleme: 

10 34 5 

Fogjuk az 5 -öt (array[jj) és összehasonlítjuk az előtte levő elemmel, ami a 34 (array[j-l]). Mivel nagyobb nála, 
ezért megcseréljük a kettőt: 

10 5 34 

Ezután csökkentjük a ciklusváltozót, ami most megint az eddigi legkisebb elemre, az 5-re fog mutatni, és 
cserélhetjük tovább. Természetesen, ha kisebb elemet találunk, akkor ezután őt fogjuk tovább vinni, egészen 
addig, amíg a legkisebb elem elfoglalja a tömb első indexét. Itt jön képbe a külső ciklus, ami azt biztosítja, hogy 
a rendezett elemeket már ne vizsgáljuk, hiszen a belső ciklus minden futásakor a tömb elejére tesszük az 
aktuális legkisebb elemet. Nézzünk meg egy másik megoldást is: 


fór (int i = 1; i < array.Length; ++i) 

{ 

int y = array[i]; 
int j = i - 1; 

while (j > -1 && y < array[j]) 

{ 

array[j + 1] = array[j]; 

--j; 

} 

array[j + 1] = y; 

} 
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Itt lényegében ugyanarról van szó, csak most elölró'l vizsgáljuk az elemeket. 


Nem árt tudni, hogy a buborékos rendezés csak kis elemszám esetében hatékony, nagyjából 0(n A 2) 
nagyságrendű. 


Az 0() (ún. nagy ordó) jelölést használjuk egy algoritmus futásidejének megbecsülésére (illetve használják a 
matematika más területein is). 
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Objektumorientált programozáselmélet 


A korai programozási nyelvek nem az adatokra, hanem a műveletekre helyezték a hangsúlyt, mert akkoriban 
még főleg matematikai számításokat végeztek a számítógépekkel. Ahogy aztán a számítógépek széles körben 
elterjedtek, megváltoztak az igények, az adatok pedig túl komplexekké váltak ahhoz, hogy a procedurális 
módszerrel kényelmesen és hatékonyan kezelni lehessen őket. 

Az első objektumorientált programozási nyelv a Simula 67 volt. Tervezői (Ole-Johan Dahl és Kristen Nygaard) 
hajók viselkedését szimulálták és ekkor jött az ötlet, hogy a különböző hajótípusok adatait egy egységként 
kezeljék, így egyszerűsítve a munkát. 

Az OOP már nem a műveleteket helyezi a középpontba, hanem az egyes adatokat (adatszerkezeteket) és a 
közöttük levő kapcsolatokat (hierarchiát). 

Ebben a fejezetben az OOP elméleti oldalával foglalkozunk, a cél a paradigma megértése, gyakorlati példákkal a 
következő részekben találkozhatunk (szintén a következő részekben található meg néhány elméleti fogalom is, 
amelyek gyakorlati példákon keresztül érthetőbben megfogalmazhatók, ezért ezeket csak később tárgyaljuk, pl. 
polimorfizmus). 


UML 

Az OOP tervezés elősegítésére hozták létre az UML -t (Unified Modelling Language). Ez egy általános 
tervezőeszköz, a célja, hogy egy minden fejlesztő által ismert közös jelrendszert valósítson meg. A 
következőkben az UML eszközeit fogjuk felhasználni az adatok közötti relációk grafikus ábrázolásához. 


Osztály 

Az OOP világában egy osztály olyan adatok és műveletek összessége, amellyel leírhatjuk egy modell (vagy 
entitás) tulajdonságait és működését. Legyen például a modellünk a kutya állatfaj! Egy kutyának vannak 
tulajdonságai (pl. életkor, súly stb.) és van meghatározott viselkedése (pl. csóválja a farkát, játszik stb.). Az UML 
a következőképpen jelöl egy osztályt: 


Kutya 


Amikor programot írunk, akkor az adott osztályból (osztályokból) létre kell hoznunk egy (vagy több) példányt, 
ezt példányosításnak nevezzük. Az osztály és példány közötti különbségre jó példa a recept (osztály) és a 
sütemény (példány). A példányokat objektumnak is nevezik. 


Adattag és metódus 

Egy objektumnak az életciklusa során megváltozhat az állapota, tulajdonságai. Ezt az állapotot valahogy el kell 
tudnunk tárolni, illetve biztosítani kell a szükséges műveleteket a tulajdonságok megváltoztatásához (pl. a kutya 
eszik (ez egy művelet), ekkor megváltozik a „jóllakottság" tulajdonsága/állapota). 

A tulajdonságokat tároló változókat adattagoknak (vagy mezőnek), a műveleteket metódusoknak nevezzük. A 
műveletek összességét felületnek is hívjuk. 

Módosítsuk a diagramunkat: 


Kutya 

jollak: int 
eszikQ : void 


Az adattagokat név: típus alakban ábrázoljuk, a metódusokat pedig név(paraméterlista); visszatérési_érték 
formában. Ezekkel a fogalmakkal egy későbbi fejezet foglalkozik majd. 
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Láthatóság 


Az egyes tulajdonságokat és metódusokat nem feltétlenül kell közszemlére bocsátani. Az OOP egyik alapelve, 
hogy a felhasználó csak annyi adatot kapjon meg, amennyi feltétlenül szükséges. A kutyás példában az eszik() 
művelet magába foglalja a rágást, nyelést, emésztést is, de erró'l nem fontos tudniuk, csak az evés ténye számít. 
Ugyanígy egy tulajdonság (adattag) esetében sem jó, ha mindenki hozzájuk fér (az elfogadható, ha a közvetlen 
család hozzáfér a számlámhoz, de idegenekkel nem akarom megosztani). 

Az ó's-OOP szabályai háromféle láthatóságot fogalmaznak meg (ez nyelvtó'l függó'en bó'vülhet), a C# 
láthatóságairól a következő' részekben lesz szó. 

A háromféle láthatóság: 

• Public: mindenki láthatja (UML jelölés: +). 

• Priváté: csakis az osztályon belül elérhető, a leszármazott osztályok nem láthatják és nem is 
módosíthatják (a származtatás és öröklődés hamarosan jön) (UML jelölés: -). 

• Protected: ugyanaz, mint a priváté, de a leszármazott osztályok módosíthatják is (UML jelölés: #). 
A Kutya osztály most így néz ki: 


Kutya 

-jollak : int 
+eszik(): void 


Egységbe zárás 

A „hagyományos", nem 00 programnyelvek (pl. a C) az adatokat és a rajtuk végezhető műveleteket a program 
külön részeiként kezelik. Bevett szokás ezeket elkülöníteni egy önálló forrásfájlba, de ez még mindig nem elég 
biztonságos. A kettő között nincs összerendelés, ezért más programozók gond nélkül átírhatják egyiket vagy 
másikat, illetve hozzáférnek a struktúrákhoz, és nem megfelelően használhatják fel azokat. 

Az 00 paradigma egységbe zárja az adatokat és a hozzájuk tartozó felületet, ez az ún. egységbe zárás 
(encapsulation vagy information hiding). Ennek egyik nagy előnye, hogy egy adott osztály belső szerkezetét 
gond nélkül megváltoztathatjuk, mindössze arra kell figyelni, hogy a felület ne változzon (pl. egy autót biztosan 
tudunk kormányozni, attól függetlenül, hogy az egy személyautó, traktor vagy Forma-l-es gép). 


Öröklődés 

Az öröklődés vagy származtatás az új osztályok létrehozásának egy módja. Egy (vagy több) már létező 
osztályból hozunk létre egy újat úgy, hogy az minden szülőjének tulajdonságát örökli, vagy átfogalmazza azokat. 
A legegyszerűbben egy példán keresztül érthető meg. Legyen egy „Állat" osztályunk! Ez eléggé tág fogalom, 
ezért szűkíthetjük a kört, mondjuk a „Gerinces Állatok"-ra. Ezen belül megkülönböztethetünk „Emlős" -t vagy 
„Hüllő" -t. Az „Emlős" osztály egy leszármazottja lehet a „Kutya" és így tovább. 

Az öröklődést specializálásnak is nevezik. A specializálás során az osztályok között ún. „az-egy" (is-a) reláció áll 
fenn. így amikor azt mondjuk, hogy a „Kutya" az egy „Állat" akkor arra gondolunk, hogy a „Kutya" egy 
specializáltabb forma, amelynek megvan a saját karakterisztikája, de végeredményben egy „Állat". Ennek a 
gondolatmenetnek a gyakorlati felhasználás során lesz jelentősége. 
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A diagram a fenti példát ábrázolja. UML-ül az öröklődést „üres" nyíllal jelöljük, amely a specializált osztály felől 
mutat az általánosabbra. Az osztályok között fennálló kapcsolatok összességét hierarchiának nevezzük. 

Előfordul, hogy nem fontos számunkra a belső szerkezet, csak a felületet szeretnénk átörökíteni, hogy az 
osztályunkat fel tudja használni a programunk egy másik része (ilyen például a már említett foreach ciklus). 
Ilyenkor nem egy „igazi" osztályról, hanem egy interfészről - felületről - beszélünk, amelynek nincsenek 
adattagjai, csakis a műveleteket deklarálja. 

A C# rendelkezik önálló interfészekkel, de ez nem minden programnyelvre igaz, ezért ők egy hasonló 
szerkezetet, ún. absztrakt osztályokat használnak. Ezekben előfordulnak adattagok is, de leginkább a felület 
definiálására koncentrálnak. A C# nyelvi szinten támogat absztrakt osztályokat is, a kettő között ugyanis lényegi 
különbség van. Az interfészek az osztálytól függetlenek, csakis felületet biztosítanak (például az lEnumerable és 
lEnumerator a foreach-nek (is) biztosítanak felületet, az nem lényeges, hogy milyen osztályról van szó). Az 
absztrakt osztályok viszont egy őshöz kötik az utódokat (erre az esetre példa az „Állat" osztály, amelyben 
megadhatunk egy absztrakt „evés" metódust, amit az utódok megvalósítanak - egy krokodil máshogy eszik, 
mint egy hangya, de az evés az állatokhoz köthető valami, ezért közös). 
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Osztályok 


Osztályt a eláss kulcsszó segítségével deklarálhatunk: 


using System; 

namespace TestApp 

{ 

eláss Dog 

{ 

} 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

Console .ReadKey(); 

} 

} 

} 


Látható, hogy a főprogram és a saját osztályunk elkülönül. 


Konvenció szerint az osztálynév mindig nagybetűvel kezdődik. 


Felmerülhet a kérdés, hogy honnan tudja a fordító, hogy melyik a „fő" osztály? A helyzet az, hogy a Main 
speciális függvény, ezt a fordító automatikusan felismeri és megjelöli, mint a program belépési pontját. Igazából 
lehetséges több Main nevű metódust is létrehozni, ekkor a fordítóprogramnak meg kell adni (a /main kapcsoló 
segítségével), hogy melyik az igazi belépési pont. Ettől függetlenül ezt a megoldást, ha csak lehet, kerüljük el! 
Nézzünk egy példát: 


using System; 

eláss Programi 

{ 

static public void Main() 

{ 

Console. WriteLine( "Programi") ; 

} 

} 

eláss Program2 

{ 

static public void Main() 

{ 

Console .WriteLine( "Program2") ; 

} 

} 


Ezt a forráskódot így fordíthajuk le: 


esc /main:Programl main.es 


Futtatáskor a „Programi" szöveget fogja kiírni a program. 

A fenti példában a lehető legegyszerűbb osztályt hoztuk létre. A C++ nyelvet ismerők figyeljenek arra, hogy az 
osztály-deklaráció végén nincs kötelező pontosvessző, ugyanakkor a fordító nem szól érte, ha odaírjuk! 
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Az osztályunkból a new operátor segítségével tudunk készíteni egy példányt. 


Dog d = new Dog(); 


A new hívásakor lefut a konstruktőr, megfelelő' nagyságú hely foglalódik a memóriában, ezután pedig 
megtörténik az adattagok inicializálása is. 


Konstruktőrük 

Minden esetben, amikor egy osztályt példányosítunk, egy speciális metódus a konstruktőr fut le, melynek 
feladata, hogy „beállítsa" az osztály értékeit. Bár a fenti osztályunkban nem definiáltunk semmi ilyesmit, ettől 
függetlenül rendelkezik alapértelmezett (azaz paraméter nélküli) konstruktorral. Ez igaz minden olyan osztályra, 
amelynek nincs konstruktora (amennyiben bármilyen konstruktőrt létrehoztunk, akkor ez a lehetőség 
megszűnik). 

Az alapértelmezett konstruktőr legelőször meghívja a saját ősosztálya alapértelmezett konstruktőrét. Ha nem 
származtattunk direkt módon (mint a fenti programban), akkor ez a System.Object konstruktora lesz 
(tulajdonképpen ez előbb vagy utóbb mindenképpen meghívódik, hiszen az ősosztály konstruktora is meghívja 
a saját ősét és így tovább). 

Abban az esetben, ha az ősosztály nem tartalmaz alapértelmezett konstruktőrt (mert van neki paraméteres), 
akkor valamely másik konstruktőrét explicit módon hívni kell a leszármazott osztály konstruktőréből a base 
metódussal, minden más esetben fordítási hiba az eredmény. 


eláss Base 

{ 

public Base(stning s) { } 

} 

eláss Denived : Base 

{ 

} 


Ez a forráskód(részlet) nem fordul le, mivel a Base osztály csakis paraméteres konstruktorral rendelkezik. 


eláss Base 


{ 


public Base(stning 

s) { } 

} 


eláss Denived : Base 


{ 


public DerivedQ : 

base("abc") { } 

} 



így már viszont működni fog. 


A base nem összekeverendő a Base nevű osztállyal, ez egy önálló metódus, amely minden esetben az ősosztály 
valamely konstruktőrét hívja. 


Az alapértelmezett konstruktőr valamilyen formában minden esetben lefut, akkor is, ha az osztályban 
deklaráltunk paraméterest, hiszen továbbra is ez felel a memóriafoglalásért. 


Egy osztály példányosításához a példányosítást végző programrész számára látható kell legyen a 
példányosítandó osztály konstruktora. 
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Az adattagok - ha vannak - automatikusan a nekik megfelelő nullértékre inicializálódnak(pl: int-> 0, bool- 
>false / referencia- és nullable típusok ->null). 

A C++ nyelvet ismerők vigyázzanak, mivel itt csak alapértelmezett konstruktőrt kapunk automatikusan, 
értékadó operátort illetve másoló konstruktőrt nem! Ugyanakkor minden osztály a System.Object-ből 
származik (még akkor is, ha erre nem utal semmi), ezért néhány metódust (például a típus lekérdezéséhez) a 
konstruktőrhöz hasonlóan azonnal használhatunk. 

Jelen pillanatban az osztályunkat semmire nem tudjuk használni, ezért készítsünk hozzá néhány adattagot és 
egy konstruktőrt: 


using System; 

namespace TestApp 

{ 

eláss Dog 

{ 

priváté string name; 
priváté int age; 

public Dog(string name, int age) 

{ 

this.name = name; 
this.age = age; 

} 

} 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

Dog d = new Dog("Füli", 2); 
Console .ReadKey(); 

} 

} 

} 


A konstruktőr neve meg kell, hogy egyezzen az osztály nevével, és semmilyen visszatérési értéke nem lehet. A 
mi konstruktőrünk két paramétert vár, a nevet és a kort (metódusokkal és paramétereikkel a következő rész 
foglalkozik bővebben). 

Egy osztálynak paraméterlistától függően bármennyi konstruktora lehet, és egy konstruktőrből hívhatunk egy 
másikat a this-szel: 


eláss Test 



{ 





public 

Test() : 

this(10) { } 


public 

Test(int 

x) { } 

} 





Ha több konstruktőr is van, akkor a paraméter típusához leginkább illeszkedő fut le. 

A példában a konstruktőr törzsében értéket adtunk a mezőknek a this hivatkozással, amely mindig arra a 
példányra mutat, amelyen meghívták (a this kifejezés így minden olyan helyen használható, ahol az 
osztálypéldányra van szükség). Nem kötelező használni, ugyanakkor hasznos lehet, hogyha sok 
adattag/metódus van, illetve ha a paraméterek neve megegyezik az adattagokéval. A fordítóprogram 
automatikusan „odaképzeli" magának a fordítás során, így mindig tudja, mivel dolgozik. 
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Az adattagok priváté elérésűek (Id. elméleti rész), azaz most csakis az osztályon belül használhatjuk és 
módosíthatjuk őket, például a konstruktorban. 

Nemcsak a konstruktorban adhatunk értéket a mezőknek, hanem használhatunk ún. inicializálókat is: 


eláss Dog 

{ 

priváté string name = "Rex"; 
priváté int age = 5; 

public Dog(string name, int age) 

{ 

this.name = name; 
this.age = age; 

} 

} 


Az inicializálás mindig a konstruktőr előtt fut le, ez egyben azt is jelenti, hogy az utóbbi felülbírálhatja. Ha a Dog 
osztálynak ezt a módosított változatát használtuk volna fentebb, akkor a példányosítás során minden esetben 
felülírnánk a kutya - alapértelmezetten megadott - korát. 


Az inicializálás sorrendje megegyezik a deklarálás sorrendjével (felülről lefelé halad). 


A konstruktőrök egy speciális változata az ún. másoló- vagy copy-konstruktor. Ez paramétereként egy saját 
magával megegyező típusú objektumot kap, és annak értékeivel inicializálja magát. Másoló konstruktőrt 
általában az értékadó operátorral szoktak implementálni, de az operátor-kiterjesztés egy másik fejezet témája, 
így most egyszerűbben oldjuk meg: 


eláss Dog 

{ 

priváté string _name = "Rex"; 
priváté int _age = 5; 

public Dog(string name, int age) 

{ 

this.name = name; 
this.age = age; 

} 

public Dog(Dog otherDog) 

: this(otherDog.name, otherDog.age) 

{ } 

} 


A program első ránézésre furcsa lehet, mivel privát elérhetőségű tagokat használunk, de ezt minden gond 
nélkül megtehetjük, mivel a C# a privát elérhetőséget csak osztályon kívül érvényesíti, ugyanolyan típusú 
objektumok látják egymást. 

Most már használhatjuk is az új konstruktőrt: 


Dog d = new Dog("Füli", 2);; 
Dog e = new Dog(d); 


Adattagok 

Az adattagok vagy mezők olyan változók, amelyeket egy osztályon (vagy struktúrán) belül deklaráltunk. Az 
adattagok az osztálypéldányhoz tartoznak (azaz minden egyes példány különálló adattagokkal rendelkezik), 
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vele születnek és „halnak" is meg. Az eddigi példáinkban is használtunk már adattagokat, ilyenek voltak a Dog 
osztályon belüli name és age változók. 

Az adattagokon használhatjuk a const típusmódosítót is, ekkor a deklarációnál értéket kell adnunk a mezó'nek, 
hasonlóan az eló'zó' fejezetben említett inicializáláshoz. Ezek a mezó'k pontosan ugyanúgy viselkednek, mint a 
hagyományos konstansok. 


Egy konstans mezó't nem lehet statikusnak (statikus tagokról hamarosan) jelölni, mivel a fordító egyébként is 
úgy fogja kezelni (ha egy adat minden objektumban változatlan, felesleges minden alkalommal külön példányt 
készíteni beló'le), vagyis minden konstans adattagból globálisan - minden példányra vonatkozóan - egy darab 
van. 


A mezó'kön alkalmazható a readonly módosító is, ez két dologban különbözik a konstansoktól: az értékadás 
elhalasztható a konstruktőrig, és az értékül adott kifejezés eredményének nem szükséges ismertnek lennie 
fordítási időben. 


Láthatósági módosítók 

Korábban beszéltünk az OOP láthatóságairól. A C# az „alap" háromhoz még kettőt hozzátesz: 

• public: az osztályon/struktúrán kívül és belül teljes mértékben hozzáférhető. 

• priváté: csakis a tartalmazó osztályon belül látható, a leszármazottak sem láthatják, 
osztályok/struktúrák esetében az alapértelmezés. 

• protected: csakis a tartalmazó osztályon és leszármazottain belül látható. 

• internál: csakis a tartalmazó (és a barát) assembly(ke)n belül látható. 

• protected internál: a protected és internál keveréke. 

Ezek közül leggyakrabban az első hármat fogjuk használni. 


Parciális osztályok 

C# nyelvben létrehozhatunk ún. parciális (darab, töredék) osztályokat (partial eláss), ha egy osztály¬ 
deklarációban használjuk a partial kulcsszót (ezt minden darabnál meg kell tennünk). Egy parciális osztály 
definíciója több részből (tipikusan több forrásfájlból) állhat. Egy parciális osztály minden töredékének 
ugyanazzal a láthatósági módosítóval kell rendelkeznie, valamint az egyik résznél alkalmazott egyéb módosítók 
(pl. abstract), illetve az ősosztály deklaráció a teljes osztályra (értsd: minden töredékre) érvényes lesz (ebből 
következik, hogy ezeket nem kötelező feltüntetni minden darabnál). Ugyanakkor ennél az utolsó feltételnél 
figyelni kell arra, hogy ne adjunk meg egymásnak ellentmondó módosítókat (pl. egy osztály nem kaphat 
abstract és sealed módosítókat egy időben). 

Nézzünk egy példát: 


// main.es 
using System; 

partial eláss PClass 

{ 

} 

eláss Program 

{ 

static public void Main() 
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{ 

PClass p = new PClass(); 

p.D°(); 

} 

} 


Látható, hogy egy olyan metódust hívtunk, amelynek hiányzik a deklarációja. 
Készítsünk egy másik forrásfájlt is: 


// pantial.es 
using System; 

pantial eláss PClass 

{ 

public void Do() 

{ 

Console.WniteLine("Hello !"); 

} 

} 


A két fájlt így tudjuk fordítani: 


esc main.es partial.es 


A .NET a parciális osztályokat fó'ként olyan esetekben használja, amikor az osztály egy részét a fordító generálja 
(pl. a grafikus felületű alkalmazásoknál a kezdeti beállításokat az InitializeComponent metódus végzi, ezt teljes 
egészében a fordító készíti el). Ennek a megoldásnak az a nagy előnye, hogy könnyen ki tudjuk egészíteni 
ezeket a generált osztályokat. 


Bármelyik osztály (tehát a nem-parciális is) tartalmazhat beágyazott parciális osztályt, ekkor értelemszerűen a 
töredékek a tartalmazó osztályon belül kell legyenek (ugyanez nem vonatkozik a parciális osztályon belül lévő 
parciális osztályokra, ott a beágyazott osztályok töredékei szétoszolhatnak a tartalmazó osztály darabjai 
között). 


Egy parciális osztály darabjainak ugyanabban az assemblyben kell lenniük. 


A C# 3.0 már engedélyezi parciális metódusok használatát is, ekkor a metódus deklarációja és definíciója 
szétoszlik: 


pantial eláss PClass 

{ 

pantial void Do(); 

} 

pantial eláss PClass 

{ 

pantial void Do() 

{ 

Console.WniteLine( "Hello! "); 

} 

} 


Parciális metódusnak nem lehet elérhetőségi módosítója (épp ezért minden esetben priváté elérésű lesz) 
valamint void-dal kell visszatérnie. 

A partial kulcsszót ilyenkor is ki kell tenni minden előfordulásnál. Csakis parciális osztály tartalmazhat parciális 
metódust. 
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Beágyazott osztályok 


Egy osztály tartalmazhat metódusokat, adattagokat és más osztályokat is. Ezeket a „belső"' osztályokat 
beágyazott (nested) osztálynak nevezzük. Egy ilyen osztályt általában elrejtünk, de ha mégis publikus 
elérésűnek deklaráljuk, akkor a „külső" osztályon keresztül érhetjük el. A beágyazott osztályok alapértelmezés 
szerint privát elérésűek. 


eláss Outer 

{ 

eláss Inner 

{ 

// a beágyazott osztály nem látható 

} 


eláss Outer 

{ 

public eláss Inner 

{ 

// így már látszik 

} 

} 

II ... 

Outer.Inner x = new Outer.InnerQ; // példányosítás 


Egy beágyazott osztály hozzáfér az őt tartalmazó osztálypéldány minden tagjához (beleértve a priváté elérésű 
tagokat és más beágyazott osztályokat is), de csakis akkor, ha a beágyazott osztály tárol egy, a külső osztályra 
hivatkozó referenciát: 


eláss Outer 

{ 

priváté int value = 11; 
priváté Inner child; 

public Outer() 

{ 

child = new Inner(this); 

} 

public void Do() 

{ 

child.Do(); 

} 

eláss Inner 

{ 

Outer parent; 

public Inner(Outer o) 

{ 

parent = o; 

} 

public void Do() 

{ 

Console.WriteLine(parent.value); 

} 

} 

} 
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Objektuminicializálók 


A C# 3.0 objektumok példányosításának egy érdekesebb formáját is tartalmazza: 


using System; 

namespace TestApp 

{ 

eláss Person 

{ 

public Person() { } 

priváté string name; 
public string Name 
{ 

get { return name; } 
set { name = value; } 

} 

} 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

Person p = new Person() 

{ 

Name = "István" 

}; 

Console.WriteLine(p.Name); 
Console .ReadKey(); 

} 

} 

} 


Ilyen esetekben vagy egy nyilvános tagra, vagy egy tulajdonságra hivatkozunk (ez utóbbit használtuk). 
Természetesen, ha létezik paraméteres konstruktőr, akkor is használhatjuk ezt a beállítási módot. 


Destruktorok 

A destruktorok a konstruktőrökhöz hasonló speciális metódusok, amelyek az osztály által használt eró'források 
felszabadításáért felelősek. 

A .NET ún. automatikus szemétgyűjtő (garbage collector) rendszert használ, amelynek lényege, hogy a 
hivatkozás nélküli objektumokat (nincs rájuk mutató érvényes referencia) a keretrendszer automatikusan 
felszabadítja. 


Person p = new Person(); // mc egy Person objektumra mutat 
p = null; // az objektumra már nem mutat semmi, felszabadítható 


Objektumok alatt ebben a fejezetben csak és kizárólag referenciatípusokat értünk, az értéktípusokat nem a GC 
kezeli. 


A szemétgyűjtő működése nem determinisztikus, azaz előre nem tudjuk megmondani, hogy mikor fut le, 
ugyanakkor kézzel is meghívható, de ez nem ajánlott. A következő példában foglalunk némi memóriát, majd 
megvizsgáljuk, hogy mi történik felszabadítás előtt és után: 
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using System; 

namespace TestApp 
{ 

eláss Program 
{ 

static void Main(string[] args) 

{ 

Console.WriteLine( "Foglalt memória: 
GC.GetTotalMemory(false) ); 


{0}", 

fór (int i = 0; i < 10; ++i) 

{ 

int[] x = new int[1000]; 

} 

Console.WriteLine( "Foglalt memória: 
GC. GetTotalMemory (false) ); 

{0}", 

GC.Collect(); // meghívjuk a szemétgyűjtőt 

Console.WriteLine( "Foglalt memória: 
GC. GetTotalMemory (false) ); 

{0}", 

Console. ReadKeyQ; 

} 

} 

} 



A GC osztály GetTotalMemory függvénye a program által lefoglalt byte-ok számát adja vissza, paraméterként 
pedig megadhatjuk, hogy meg szeretnénk-e hívni a szemétgyűjtőt. 

A fenti program kimenete valami ilyesmi lesz, az értékek persze változhatnak: 


Foglalt memória: 21060 
Foglalt memória: 70212 
Foglalt memória: 27144 


Vegyük észre, hogy a ciklusban létrehozott tömbök minden ciklus végén eltüntethetőek, mivel nincs többé 
rájuk hivatkozó referencia (hiszen a lokális objektumok hatóköre ott véget ér)! 

De hogyan is működik a szemétgyűjtő? A .NET ún. generációs garbage collector-t használ, amely abból a 
feltevésből indul ki, hogy a legfrissebben létrehozott objektumok lesznek leghamarabb felszabadíthatóak (ez az 
ún. generációs hipotézis) (gondoljunk csak a lokális változókra, amelyeket viszonylag sokat használunk). 

Ez alapján a következő történik: minden friss objektum a nulladik - legfiatalabb - generációba kerül. Amikor 
eljön a szemétgyűjtés ideje, a GC először ezt a generációt vizsgálja meg, és ha talál hivatkozás nélküli 
objektumot azt törli (pontosabban az elfoglalt memóriaterületet szabadnak jelöli), a maradékot pedig átrakja 
az első generációba. Ezután sorban átvizsgálja a többi generációt (még kettő van), és elvégzi a megfelelő 
módosításokat. Értelemszerűen a második generációs objektumok akkor törlődnek, ha a program megáll 
(illetve elfogyhat a memória is, ekkor OutOfMemoryException kivétel keletkezik). Az egyes generációk 
összefüggő memóriaterületen vannak, így kevesebbet kell dolgoznia a gyűjtőnek. 

Az is érdekes kérdés, hogy honnan tudja a GC, hogy melyik objektumok feleslegesek. Ehhez be kell vezetnünk 
két fogalmat, a gyenge illetve erős referenciák (weak- és strong-reference) intézményét: 

• Minden olyan objektumra, amelyet a new operátorral hozunk létre, erős referenciával hivatkozunk, 
ezek „normális" objektumok, amelyek akkor és csakis akkor kerülnek hatókörön kívülre (és 
takaríthatóak el a GC által), ha nincs rájuk hivatkozó érvényes referencia. 
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• A gyenge referenciák ennek épp ellenkezőjét nyújtják, bármikor törölhető az általuk mutatott 
objektum, ha nincs elég memória - akkor is, ha létezik rá mutató érvényes - gyenge - hivatkozás. 

A .NET nyelvi szinten támogatja a gyenge referenciákat: 


int[][] annay = new int[10][]; 
fon (int i = 0; i < 10; ++i) 

{ 

annay[i] = new int[1000]; 

} 

WeakRefenence wn = new WeakReference(array) ; 
annay = null; 


Ebben a példában miután az eredeti tömbhivatkozást null-ra állítottuk, a tömb objektumokra már csak gyenge 
referencia mutat, azaz bármikor eltakarítható. 

Egy WeakReference objektumból „visszanyerhető" az eredeti erős referencia a Target tulajdonság segítségével, 
viszont ne felejtsük el ellenőrizni ennek nullértékét, mert lehet, hogy már átment rajta a GC (és konvertálnunk 
is kell, mivel object típussal tér vissza): 


WeakRefenence wn = new WeakRefenence(annay) ; 
annay = null; 

if (wn.Tanget != null) 

{ 

int[][] annay = (int[] [])wn.Tanget; 

} 


A másik fogalom, amelyet ismernünk kell, az az ún. application root objektumok. Ezek olyan objektumok, 
amelyekről feltételezhetjük, hogy elérhetőek (ilyen objektumok lesznek pl. az összes lokális és globális változó). 
A GC mindig a root objektumokat vizsgálja meg először, és rajtuk keresztül építi fel a memóriatérképet. 

Most már tisztában vagyunk az alapokkal, vizsgáljuk meg, hogy mi történik valójában! Azt mondtuk, hogy a GC 
átvizsgálja a generációkat, ennek azonban van egy kis hátránya, mégpedig az, hogy lassú. Ahhoz, hogy a 
takarítás valóban hatékony legyen, fel kell függeszteni a program futását, vagy azzal párhuzamosan dolgozni. 
Mindkét esetben rosszul járunk, hiszen vagy „lefagy" a program egy időre, vagy kevesebb erőforráshoz jut 
(ugyanakkor azt is számításba kell venni, hogy a GC a lehető legjobb időben - értsd: akkor, amikor a program a 
legkevesebb erőforrást használja - fog beindulni, tehát nem feltétlenül fog igazán nagy gondot jelenteni az 
alkalmazás szempontjából). Nyilván többmagos processzorral szerelt PC -knél jobb a helyzet, de attól még 
fennáll a hatékonyság problémája. 

Épp ezért, ahelyett, hogy minden alkalommal teljes vizsgálatot végezne a GC, bevezették a részleges takarítás 
fogalmát, amely a következő feltevésre épül: az egyes illetve kettes generációkban lévő objektumok nagy 
valószínűséggel nem módosultak, vagyis feltehetjük, hogy van rájuk hivatkozó referencia (gondoljunk arra, hogy 
pl. a lokális változók szinte soha nem fognak átkerülni még az egyes generációba sem, vagyis az egyes és kettes 
generáció tagjai tipikusan hosszú életű objektumok lesznek). Természetesen ezt nem tudhatjuk biztosan, ezért 
minden .NET alkalmazáshoz automatikusan létrejön egy adatszerkezet (képzeljük el tömbként), amelynek egyes 
indexei a memória egy bizonyos nagyságú területének állapotát mutatják (nem az objektumokét!). 

Tehát eljön a GC ideje, átválogatja a nulladik generációt, majd fogja a fenti adatszerkezetet (ún. card table), és 
megvizsgál minden olyan objektumot, amely olyan memóriaterületen fekszik, amelyet a card table 
módosítottnak jelölt. Ez drámaian megnöveli a GC hatékonyságát, hiszen a teljes felhasznált memóriának csak 
töredékét kell megvizsgálnia. 

A GC a nevével ellentétben nem csak ennyit tesz, valójában az ő dolga az objektumok teljes életciklusának a 
kezelése és a memória megfelelő szervezése is. 

Amikor elindítunk egy .NET programot, akkor a GC elsőként szabad memóriát kér az operációs rendszertől (a 
.NET ún. szegmensekre osztja a memóriát, minden szegmens 16 MB méretű), mégpedig kétszegmensnyit: 
egyet a hagyományos objektumoknak (GC Heap) és egyet a nagyméretű (100+ kilobyte) objektumoknak (LOH - 
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Large Object Heap, ezt csakis teljes takarításnál vizsgálja a GC). Ezután nyugodtan készíthetünk objektumokat, 
mert ha elfogy a hely, a GC automatikusan új szegmenseket fog igényelni. 

Azt gondolná az ember, hogy ennyi az egész, de minden objektum életében eljön a pillanat, amikor visszaadja a 
lelkét a teremtőjének, nevezetesen a GC-nek. Ilyenkor rá hárul az a rendkívül fontos feladat is, hogy rendbe 
rakja a memóriát. Mit is értünk ez alatt? Hatékonyság szempontjából az a legjobb, ha az osztálypéldányok 
egymáshoz közel - lehetőleg egymás mellett - vannak a memóriában. Épp ezért a GC minden (fő)gyűjtőciklus 
(tehát teljes takarítás) alkalmával átmozgatja az objektumokat, hogy a lehető leghatékonyabban kezelhessük 
őket. 


Ennek a megoldásnak egy hátulütője, hogy ilyen módon nem használhatunk unmanaged kódot, mivel ez teljes 
mértékben megakadályozza a pointerműveleteket. A megoldást az objektumok rögzítése (ún. pinning) jelenti, 
erről egy későbbi fejezet számol be. 

A managelt kód éppen a fenti tények miatt tudja felvenni a versenyt a natív programokkal. Sőt, olyan 
alkalmazások esetében, ahol sokszor foglalunk és szabadítunk fel memóriát, a natív kód hátrányba is kerül(het). 
Összességében azt mondhatjuk, hogy natív és managelt program között nincs nagy különbég sebesség 
tekintetében. 


A GC háromféle módban tud működni: 

• A GC párhuzamosan fut az alkalmazással 

• A GC felfüggesztheti az alkalmazást 

• Szerver mód 

Nézzük az elsőt: az objektumok allokálását egy különálló szál végzi, ha szükség van tisztításra, akkor a program 
többi szálát csak nagyon rövid ideig függeszti fel, és a takarítással egyidejűleg a program továbbra is helyet 
foglalhat a memóriában, kivéve, ha az átlépte a maximálisan kiszabott keretet. Ez a limitálás a nulladik 
generációra vonatkozik, tehát azt szabja meg, hogy mennyi memóriát használhat fel egyszerre a GO 
(amennyiben ezt az értéket elérjük, a GC beindul). Ezt a módszert olyan alkalmazásoknál használjuk, amikor 
fontos, hogy felhasználói felület reszponzív maradjon. Ez az alapértelmezett mód. 

Hasonlóan működik a második is, viszont ő teljes mértékben „leállítja" az alkalmazást (ún. Stop-The-World 
módszer) a tisztítás idejére. Ez a mód sokkal kisebb GO kerettel rendelkezik. 

Szerver módban minden egyes processzor külön heap-pel és GC-vel rendelkezik. Ha egy alkalmazás kifut a 
memóriából, szól a GC-nek, amely felfüggeszti a program futását a tisztítás idejére. 

Ha meg akarjuk változtatni egy program GC módját, szükségünk lesz egy konfigurációs fájlra (erről egy későbbi 
fejezetben), amely a következőket tartalmazza (a példában kikapcsoljuk a párhuzamos futást): 


<configuration> 

<runtime> 

<gcConcurrent enabled="false"/> 
</runtime> 

</configuration> 

Vagy: 


<configuration> 

<runtime> 

<gcServer enabled="true"/> 
</runtime> 

</configuration> 


Ezzel pedig a szervermódot állítottuk be. 
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Most pedig megnézzük, hogy hogyan használhatjuk a GC -t a gyakorlatban. A konstruktor(ok) mellett egy másik 
speciális metódust is kaphat minden referenciatípus, ez pedig a destruktor. Ugyanakkor a konstruktőrtől 
eltéró'en destruktor nem jön létre automatikusan, csakis ha magunk definiáltuk. 

A GC megsemmisítés előtt az objektumokon meghívja a hozzájuk tartozó destruktort, más néven Finalizer-t. 
Ennek a metódusnak a feladata, hogy felszabadítsa az osztály által használt erőforrásokat (pl., hogy lezárja a 
hálózati kapcsolatokat, bezárjon minden egyes megnyitott fájlt stb.). Vegyük a következő kódot: 


using System; 

namespace TestApp 

{ 

eláss DestructableClass 

{ 

public DestructableClass() 

{ 

Console. WriteLine( "Konstruktőr") ; 

} 

~DestructableClass() 

{ 

Console.WriteLine( "Destruktor") ; 

} 

} 

eláss Program 

{ 

static void Main(string[] args) 

{ 

DestructableClass de = new DestructableClass(); 
Console .ReadKey(); 

} 

} 


A destruktor neve tilde jellel (~) kezdődik, neve megegyezik az osztályéval, és nem lehet semmilyen módosítója 
vagy paramétere (értelemszerűen egy destruktor mindig privát elérhetőségű lesz, vagyis közvetlenül soha nem 
hívhatjuk, ez csakis a GC előjoga). 


Soha ne készítsünk üres destruktort, mivel a GC minden destruktorról bejegyzést készít, és mindenképpen 
meghívja mindegyiket - akkor is, ha üres, vagyis ez felesleges metódushívás lenne. 


Ha lefordítjuk ezt a kódot és elindítjuk a programot, először a „Konstruktőr" szót fogjuk látni, majd egy gomb 
lenyomása után megjelenik a párja is. Ha látni is akarjuk, nem árt parancssorból futtatni, de egy villanásnyi 
időre Visual Studio-ból futtatva is látható. A fenti kód valójában a következő formában létezik: 


eláss DestructableClass 

{ 

public DestructableClass() 

{ 

Console. WriteLine( "Konstruktőr") ; 

} 

protected override void FinalizeQ 

{ 

try 

{ 

Console. WriteLine( "Destruktor") ; 

} 

finally 

{ 
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} 


} 


base.Finalize(); 

} 


Ez a forráskód csak példa, nem fordul le, mivel a Finalize metódust nem definiálhatjuk felül, erre való a 
destruktor. 

A Finalize-t minden referenciatípus örökli a System.Object-től. Eló'ször felszabadítja az osztály erőforrásait (a 
destruktorban általunk megszabott módon), azután meghívja az ősosztály Finalize metódusát (ez legalább a 
System.Object destruktora lesz) és így tovább, amíg a lánc végére nem ér: 


using System; 

namespace TestApp 

{ 

eláss Base 

{ 

~Base() 

{ 

Console.WriteLine( "Base") ; 

} 

} 

eláss Derived : Base 

{ 

~Derived() 

{ 

Console .WriteLine( "Derived" ); 

} 

} 


eláss Program 

{ 

static void Main(string[ ] args) 

{ 

Derived d = new Derived(); 
Console .ReadKey(); 

} 

} 

} 


A destruktorokra vonatkozik néhány szabály, ezek a következők: 

• Egy osztálynak csak egy destruktora lehet 

• A destruktor nem örökölhető 

• A destruktort nem lehet direkt hívni, a hívás mindig automatikusan történik 

• Destruktora csakis osztálynak lehet, struktúrának nem 


Legtöbbször felesleges destruktort készíteni, ez csak néhány speciális esetben szükséges, pl. amikor valamilyen 
unmanaged erőforrást (memória, fájl stb...) használunk. 


IDisposable 

Az IDisposable interfész segítségével egy osztály által használt erőforrások felszabadítása kézzel - előre 
meghatározott időpontban - is megtörténhet, tehát nem kell a GC -re várni. 


using System; 
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namespace TestApp 

{ 

eláss DisposableClass : IDisposable 

{ 

public void DisposeQ 

{ 

// Takarítunk 
GC.SuppressFinalize(this); 

} 

} 

eláss Program 

{ 

static void Main(string[] args) 

{ 

DisposableClass de = new DisposableClassQ; 
Console .ReadKey(); 

} 

} 


Az interfész által deklarált Dispose metódusban meg kell hívnunk a GC.SuppressFinalize metódust, hogy 
jelezzük a GC-nek, hogy ez az osztály már felszabadította az eró'forrásait, és nem kell destruktort hívnia. 


A fenti kódban egy kicsit csaltunk: a SuppressFinalize csak akkor kell, ha valóban definiáltunk destruktort, 
egyébként felesleges. 


Destruktorok használata helyett általában az ún. Dispose tervezési mintát alkalmazzuk, amely megvalósításához 
nyilván az IDisposable interfész lesz segítségünkre. 


eláss DisposableClass : IDisposable 

{ 

priváté bool disposed = false; 

public void DisposeQ 

{ 

Dispose(true) ; 

GC.SuppressFinalize(this); 

} 

priváté void Dispose(bool disposing) 

{ 

if (!disposed) 

{ 

if (disposing) 

{ 

// managed erőforrások felszabadítása 

} 

// unmanaged erőforrások felszabadítása 

disposed = true; 

} 

} 

~DisposableClass() 

{ 

Dispose(false) ; 

} 

} 
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Ebben a forráskódban két Dispose metódust készítettünk, az első paraméter nélküli az, amit az interfésztől 
kaptunk, míg a másik arra szolgál, hogy összehangoljuk a GC munkáját a kézi erőforrás-felszabadítással. 

Ha a második metódus paramétere true értékű a híváskor, akkor tudjuk, hogy kézzel hívtuk a Dispose 
metódust, vagyis mind a menedzselt, mind a natív erőforrások felszabadíthatóak. Ha a paraméter értéke false, 
akkor pedig a hívás a destruktorból származik, vagyis csak az unmanaged erőforrásokkal kell törődnünk. 

Az IDisposable interfészt megvalósító osztályok használhatóak ún. using blokkban, ami azt jelenti, hogy a blokk 
hatókörén kívülre érve a Dispose metódus automatikusan meghívódik: 


using System; 

namespace TestApp 

{ 

eláss DisposableClass : IDisposable 

{ 

public void DisposeQ 

{ 

Console.WriteLine("Takarítunk. .. 
GC.SuppnessFinalize(this); 

} 

} 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

using (DisposableClass de = new DisposableClass( )) 

{ 

} 

Console .ReadKey(); 

} 

} 

} 


A program kiírja a „Takarítunk..." szöveget, ahogy elhagyja a vezérlés a using blokkot. A legtöbb l/O művelettel 
(fájl- és hálózatkezelés) kapcsolatos osztály megvalósítja az IDisposable -t, ezért ezeket ajánlott mindig using 
blokkban használni. 
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Metódusok 


Az objektumorientált programozásban egy metódus olyan programrész, amely vagy egy objektumhoz, vagy egy 
osztályhoz köthető. Előbbi az ún. osztály metódus, utóbbi pedig a statikus metódus. Ebben a fejezetben az 
osztály (instance) metódusokról lesz szó. 

Egy metódussal megváltoztathatjuk egy objektum állapotát, vagy információt kaphatunk annak adatairól. 
Optimális esetben egy adattaghoz csakis metódusokon keresztül férhetünk hozzá (ez akkor is igaz, ha látszólag 
nem így történik, pl. minden operátor valójában metódus formájában létezik, ezt majd látni fogjuk). 

Bizonyára szeretnénk, ha a korábban elkészített kutya osztályunk nemcsak lógna a semmiben, hanem tenne is 
valamit. Készítsünk néhány metódust a legfontosabb műveletekhez: az evéshez és az alváshoz: 


using System; 

namespace TestApp 

{ 

eláss Dog 

{ 

stning name; 
int age; 

public Dog(stning name, int age) 

{ 

this.name = name; 
this.age = age; 

} 

public void Eat() 

{ 

Console.WriteLine("A kutya eszik..."); 

} 

public void Sleep() 

{ 

Console.WriteLine("A kutya alszik..."); 

} 

} 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

Dog d = new Dog("Füli", 4); 

d.Eat(); 

d.Sleep(); 

Console .ReadKey(); 

} 

} 

} 


Nézzük meg, hogyan épül fel egy metódus! Elsőként megadjuk a láthatóságot, és itt is érvényes a szabály, hogy 
ennek hiányában az alapértelmezett privát elérés lesz érvényben. Ezután a visszatérési érték típusa áll, jelen 
esetben a void-dal jeleztük, hogy nem várunk ilyesmit. Következik a metódus neve, ez konvenció szerint 
nagybetűvel kezdődik, végül a sort a paraméterlista zárja. 

Egy metódust az objektum neve után írt pont operátorral hívhatunk meg (ugyanez érvényes a publikus 
adattagokra, tulajdonságokra stb. is). 
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A „hagyományos" procedurális programozás (pl. a C vagy Pascal nyelv) a metódusokhoz hasonló, de 
filozófiájában más eszközöket használ, ezek a függvény (function) és az eljárás (procedure). Mi a különbség? Azt 
mondtuk, hogy a metódusok egy osztályhoz köthetőek, annak életciklusában játszanak szerepet. 

Nézzünk egy példát: 


using System; 

namespace TestApp 

{ 

eláss NewStningl 

{ 

priváté string aString; 

public NewStringl(string s) 

{ 

this. aString = s; 

} 

public void PrintUpper() 

{ 

Console .WriteLine( this .aString.ToUpper()); 

} 

} 

eláss NewString2 

{ 

public void PrintUpper(string s) 

{ 

Console.WriteLine(s .Tollpper()); 

} 

} 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

NewStringl nsl = new NewStringl( "baba") ; 
NewString2 ns2 = new NewString2( ); 

nsl.PrintUpper(); 

ns2.PrintUpper("baba"); 

Console .ReadKey(); 

} 

} 

} 


Pontosan ugyanaz történik mindkét esetben, de van egy nagy különbség. Az első osztály „valódi" osztály: 
adattaggal, konstruktorral stb. Van állapota, végezhetünk rajta műveleteket. A második osztály nem igazi 
osztály, csak egy doboz, amelyben egy teljesen önálló, egyedül is életképes szerkezet van, mindössze azért kell 
az osztály-definíció, mert egyébként nem fordulna le a program (ebben az esetben egy statikus „metódust" 
kellett volna készítenünk, erről hamarosan). 

Az első osztályban metódust definiáltunk, a másodikban eljárást (eljárás és függvény között a lényegi 
különbség, hogy utóbbinak van visszatérési értéke). 
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Paraméterek 


Az objektummal való kommunikáció érdekében képesnek kell lennünk kívülről megadni adatokat, vagyis 
paramétereket. A paraméterek számát és típusait a metódus deklarációjában, vesszővel elválasztva adjuk meg. 
Egy metódusnak gyakorlatilag bármennyi paramétere lehet, de ökölszabály, hogy két paraméternél többet csak 
kivételes esetben használjunk. 

A metódus nevét és paraméterlistáját aláírásnak, szignatúrának vagy prototípusnak nevezzük. Egy osztály 
bármennyi azonos nevű metódust tartalmazhat, ameddig a paraméterlistájuk különbözik. A paraméterek a 
metóduson belül lokális változókként viselkednek, és a paraméter nevével hivatkozunk rájuk. 


using System; 

namespace TestApp 

{ 

eláss Test 

{ 

public void Method(string párám) 

{ 

Console.WriteLine("A paraméter: {0}", párám); 

} 

} 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

Test t = new Test(); 
t.Method( "Paraméter") ; 

Console .ReadKey(); 

} 

} 

} 


A C# nyelvben paramétereket átadhatunk érték és cím szerint is. Előbbi esetben teljesen új példány jön létre az 
adott osztályból, amelynek értékei megegyeznek az eredetiével. A másik esetben egy az objektumra mutató 
referencia adódik át, tehát az eredeti objektummal dolgozunk. 

Az érték- és referenciatípusok különbözően viselkednek az átadás szempontjából. Az értéktípusok 
alapértelmezetten érték szerint adódnak át, míg a referenciatípusoknál a cím szerinti átadás az előre 
meghatározott viselkedés. Utóbbi esetben van azonban egy kivétel, mégpedig az, hogy míg a referenciatípus 
értékeit megváltoztathatjuk (és ez az eredeti objektumra is hat), addig magát a referenciát már nem, tehát nem 
készíthetünk új példányt, amelyre az átadott referencia mutat. Ha ezt mégis megtesszük, az nem eredményez 
fordítási hibát, de a változás csakis a metóduson belül lesz észlelhető. 

Erre a magyarázat nagyon egyszerű: már említettük, hogy egy metódusparaméter lokális változóként viselkedik, 
vagyis ebben az esetben egyszerűen egy lokális referenciával dolgoznánk. 


using System; 

namespace TestApp 

{ 

eláss Test 

{ 

public int x = 10; 

public void TestMethod(Test t) 

{ 

t = new Test(); 
t.x = 11; 
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} 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Test t = new Test(); 
Console.WriteLine(t.x); // 10; 
t.TestMethod(t); 
Console.WriteLine(t.x); // 10 

Console.ReadKeyQ; 

} 

} 

} 


Ha mégis módosítani akarjuk egy referenciatípus referenciáját, akkor külön jeleznünk kell azt, hogy „valódi" 
referenciaként akarjuk átadni. 

Kétféleképpen adhatunk át paramétert referencia szerint. Az első' esetben az átadott objektumnak 
inicializáltnak kell lennie (tehát mindenképpen mutatnia kell valahová, használnunk kellett a new operátort). 
Ha ezt nem tettük meg, attól a program még lefordul, de a metódus hívásakor kivételt fogunk kapni 
(NullReferenceException). A referencia szerinti átadást a forráskódban is jelölni kell, mind a metódus 
prototípusánál, mind a hívás helyén a ref módosítóval. 

Referenciatípust gyakorlatilag soha nem kell ilyen módon átadnunk (persze nincs megtiltva, de gondos 
tervezéssel elkerülhető'), kivételt képez, ha ezt valamilyen .NET-en kívüli eszköz megköveteli (a lényeg, hogy 
már allokált objektumra mutató referenciát optimális esetben nem állítunk máshová). 

A ref értéktípusok esetében már sokkal hasznosabb, nézzük a következő forráskódot: 


using System; 

namespace TestApp 

{ 

eláss Test 

{ 

public void Swap(int x, int y) 

{ 

int tmp = x; 
x = y; 
y = tmp; 

} 

} 

eláss Program 

{ 

static void Main(string[] args) 

{ 

int x = 10; 
int y = 20; 

Test t = new Test(); 

t.Swap(x, y); 

Console.WriteLine("x = {0}, y = {1}", x, y); 
Console .ReadKey(); 

} 

} 

} 
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A Swap eljárással megpróbáljuk felcserélni x és y értékeit. Azért csak próbáljuk, mert int típusok (mivel 
értéktípusról van szó) érték szerint adódnak át, vagyis a metódus belsejében teljesen új változókkal dolgozunk, 
írjuk át egy kicsit a forrást: 


using System; 

namespace TestApp 

{ 

eláss Test 

{ 

public void Swap(ref int x, ref int y) 

{ 

int tmp = x; 
x = y; 

Y = tmp; 

} 

} 

eláss Program 

{ 

static void Main(string[] args) 

{ 

int x = 10; 
int y = 20; 

Test t = new Test(); 

t.Swap(ref x, ref y); 

Console.WriteLine("x = {0}, y = {1}", x, y); 
Console .ReadKey(); 

} 

} 

} 


Most már az történik, amit szeretnénk: x és y értéke megcserélődött. 


Egy érdekesebb módszer két szám megcserélésére: használjuk a kizáró vagy operátort, ami akkor ad vissza igaz 
értéket, ha a két operandusa közül pontosan az egyik igaz! Nézzük először a kódot: 

public void Swap(ref int x, ref int y) 

{ 

if (x != y) 

{ 

x A = y; 
y A = x; 
x A = y; 

} 

} 

A két számot írjuk fel kettes számrendszerben: x (= 10) = 01010 és y (= 20) =10100! Most lássuk, hogy mi 
történik! Az első sor: 

01010 
10100 XOR 


11110 (ez lesz most x) 
A második sor: 

10100 
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11110 XOR 


01010 (ez most y, ez az érték a helyén van) 

Végül a harmadik sor: 

11110 
01010 XOR 


10100 (kész vagyunk) 

Hogy ez a módszer miért működik, azt mindenki gondolja át maga, egy kis segítség azért jár: felhasználjuk a 
XOR következő tulajdonságait: 

Kommutatív: A XOR B = B XOR A 
Asszociatív: (A XOR B) XOR C = A XOR (B XOR C) 

Létezik neutrális elem (jelöljük NE -vei): A XOR NE = A 

Minden elem saját maga inverze: A XOR A = 0 (ez az állítás az oka annak, hogy ellenőriznünk kell, hogy x és y ne 
legyen egyenlő) 

Bár ez az eljárás hatékonyabbnak tűnik, igazából ez egy hagyományos PC -n még lassúbb is lehet, mint az 
átmeneti változót használó társa. 


A cím szerinti átadás másik formájában nem inicializált paramétert is átadhatunk, de ekkor feltétel, hogy a 
metóduson belül állítsuk be (átadhatunk így már inicializált paramétert is, de ekkor is feltétel, hogy új 
objektumot készítsünk). A használata megegyezik a ref-fel, azaz a szignatúrában és a hívásnál is jelezni kell a 
szándékunkat. A használandó kulcsszó az out: 


using System; 

namespace TestApp 

{ 

eláss Init 

{ 

public void TestInit(out Test t) 

{ 

t = new Test() { s = "Hello!" }; 

} 

} 

eláss Test 

{ 

public stning s = null; 

} 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Test t = null; 

Init i = new Init(); 

i.TestInit(out t); 
Console.WriteLine(t.s); // Hello! 

Console .ReadKey(); 

} 

} 

} 
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A fenti programokban pontosan tudtuk, hogy hány paramétere van egy metódusnak. Eló'fordul viszont, hogy 
ezt nem tudjuk egyértelműen megmondani, ekkor ún. paramétertömböket kell használnunk. Ha ezt tesszük, 
akkor az adott metódus paraméter-listájában a paramétertömbnek kell az utolsó helyen állnia, illetve egy 
paraméterlistában csak egyszer használható ez a szerkezet. 


using System; 

namespace TestApp 

{ 

eláss Test 

{ 

public void PnintElements(panams object[] üst) 

{ 

foreach (van item in üst) 

{ 

Console.WniteLine(item); 

} 

} 

} 


eláss Program 

{ 

static void Main(string[] args) 

{ 

Test t = new Test(); 

t.PrintElements("alma", "körte"., 4, 1, "dió"); 
t.PrintElementsQ; // ez is működik 

Console .ReadKey(); 

} 

} 

} 


A paramétertömböt a params kulcsszóval vezetjük be, ezután a metódus belsejében pontosan úgy viselkedik, 
mint egy normális tömb. Paramétertömbként átadhatunk megfelelő' típusú tömböket is. 

Alapértelmezett paraméterek 

A C# 4.0 bevezeti az alapértelmezett paramétereket, amelyek lehetővé teszik, hogy paramétereknek 
alapértelmezett értékeket adjunk, ezáltal nem kell kötelezően megadnunk minden paramétert a metódus 
hívásakor. Nézzük a következő példát: 


eláss Person 

{ 

public Person(string firstName, string lastName) 

{ 

FirstName = firstName; 

LastName = lastName; 

} 

public Person(string firstName, string lastName, string job) 
: this(firstName, lastName) 

{ 

lob = job; 

} 

public string FirstName {get; priváté set; } 
public string LastName {get; priváté set; } 
public string lob {get; priváté set; } 


109 




Mivel nem tudunk biztosan minden emberhez munkahelyet rendelni, ezért két konstruktőrt kellett 
készítenünk. Ez alapvetően nem nagy probléma, viszont az gondot okozhat, ha valaki csak az első konstruktőrt 
használja, majd megpróbál hozzáférni a munka tulajdonsághoz. Ezt sem nagy gond megoldani, de miért 
fáradnánk, ha rendelkezésünkre állnak az alapértelmezett paraméterek? írjuk át a forráskódot: 


eláss Person 

{ 

public Person(string firstName, stning lastName, string job = "N/A") 

{ 

FirstName = firstName; 

LastName = lastName; 
lob = job; 

} 

public stning FirstName { get; priváté set; } 
public string LastName { get; priváté set; } 
public string lob { get; priváté set; } 


A job paraméterhez most alapértelmezett értéket rendeltünk, így biztosak lehetünk benne, hogy minden 
adattag megfelelően inicializált. Az osztályt most így tudjuk használni: 


Person pl = new Person("István", "Reiter"); 

Person p2 = new Person("István", "Reiter",, "börtönőr"); 


Nevesített paraméterek 

A C# 4.0 az alapértelmezett paraméterek mellett bevezeti a nevesített paraméter (named paraméter) 
fogalmát, amely segítségével explicit megadhatjuk, hogy melyik paraméternek adunk értéket. Nézzük az előző 
fejezet Person osztályának konstruktőrét: 


Person p = new Person(firstName: "István"., lastName: 

"Reiter"); 

Mivel tudatjuk a fordítóval, hogy pontosan melyik paraméterre gondolunk, ezért nem kell betartanunk az 

eredeti metódus-deklarációban előírt sorrendet: 


Person p = new Person(lastName: "Reiter"., firstName: 

"István"); 


Visszatérési érték 

Az objektumainkon nemcsak műveleteket végzünk, de szeretnénk lekérdezni az állapotukat is és felhasználni 
ezeket az értékeket. Ezenkívül szeretnénk olyan függvényeket is készíteni, amelyek nem kapcsolódnak 
közvetlenül egy osztályhoz, de hasznosak lehetnek (pl. az Int.Parse függvény ilyen). 

Készítsünk egy egyszerű függvényt, amely összead két számot, az eredményt pedig visszatérési értékként 
kapjuk meg: 


using System; 

namespace TestApp 

{ 

eláss Test 

{ 

public int Add(int x, int y) 

{ 

return x + y; 

} 

} 
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eláss Program 

{ 

static void Main(string[] args) 

{ 

Test t = new Test(); 

int result = t.Add(10, 11); 

Console .ReadKey(); 

} 

} 

} 


A végeredményt a return utasítással adhatjuk vissza. A metódus-deklarációnál meg kell adnunk a visszatérési 
érték típusát is. Amennyiben ezt megtettük, a metódusnak mindenképpen tartalmaznia kell egy return 
utasítást a megfelelő' tipusú elemmel (ez lehet null is referencia- és nullable típusok esetében) és ennek az 
utasításnak mindenképpen le kell futnia: 


public int Add(int x, int y) 

{ 

if (x != 0 && y != 0) 

{ 

return x + y; 

} 

} 


Ez a metódus nem fordul le, mivel nem lesz minden körülmények között visszatérési érték, hiszen nem biztos, 
hogy x és y is nullától különböző értéket kap. 

A visszatérített érték típusának vagy egyeznie kell a visszatérési érték típusával, vagy a kettő között léteznie kell 
implicit típuskonverziónak: 


public int Add(int x, int y) 

{ 

return (byte)(x + y); // ez működik, bár nincs sok értelme 

} 

public int Add(int x, int y) 

{ 

return (long)(x + y);// ez le sem fordul 

} 


Visszatérési értékkel rendelkező metódust használhatunk minden olyan helyen, ahol a program valamilyen 
típust vár (értékadás, logikai kifejezések, metódus paraméterei, ciklusfeltétel stb.). 

Kiterjesztett metódusok 

A C# 3.0 lehetőséget ad arra, hogy egy már létező típushoz új metódusokat adjunk, anélkül, hogy azt 
közvetlenül módosítanánk, vagy származtatnánk belőle. Egy kiterjesztett metódus (extension method) minden 
esetben egy statikus osztály statikus metódusa kell, hogy legyen (erről a következő fejezetben). 

Egészítsük ki a string típust egy metódussal, ami kiírja a képernyőre az adott karaktersorozatot: 


using System; 

namespace TestApp 

{ 

static public eláss StringHelper 
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static public void Print(this string s) 

{ 

Console.WriteLine(s); 

} 

} 

eláss Program 

{ 

static void Main(string[] args) 

{ 

string s = "ezegystring"; 
s.Print(); 

StringHelper.Print(s); // így is használhatjuk 
Console .ReadKey(); 

} 

} 

} 


A this módosító után a paraméter típusa következik, amely meghatározza a kiterjesztett osztály típusát. A fenti 
példában látható, hogy „rendes" statikus metódusként is használható egy extension method. 

Ha két kiterjesztett metódus ugyanazzal a szignatúrával rendelkezik, akkor a hagyományos, statikus úton kell 
hívnunk őket. Ha nem így teszünk, akkor a speciálisabb (szűkebb típusú) paraméterű metódus fog meghívódni. 
Kiterjesztett metódust nem definiálhatunk beágyazott osztályban. 
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Tulajdonságok 


A tulajdonságokat (property) a mezők közvetlen módosítására használjuk, anélkül, hogy megsértenénk az 
egységbe zárás elvét. A tulajdonságok kívülről nézve pontosan ugyanolyanok, mint a hagyományos változók, de 
valójában ezek speciális metódusok. Minden tulajdonság rendelkezhet ún. getter és setter blokkal, előbbi a 
property mögött lévő mező értékét adja vissza, utóbbi pedig értéket ad neki: 


using System; 

namespace TestApp 

{ 

eláss Person 

{ 

public Person(string name) 

{ 

this.name = name; 

} 

stning name; 
public stning Name 
{ 

get { netunn this.name; } 
set { this.name = value; } 

} 

} 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

Person p = new Person("István"); 
Console.WriteLine(p.Name); 
Console .ReadKey(); 

} 

} 


Láthatjuk, hogy egy property deklaráció hasonlóan épül fel, mint a metódusoké, azzal a kivétellel, hogy nincs 
paraméterlista. Vegyük észre, hogy a setter-ben egy ismeretlen, value nevű változót használtunk. Ez egy 
speciális elem, azt az értéket tartalmazza, amelyet hozzárendeltünk a setter-hez: 


Person p = new Person("István"); 
p.Name = "Béla"; // value == "Béla 


A getter és setter elérhetőségének nem muszáj megegyeznie, de a getternek minden esetben publikusnak kell 
lennie: 


public string Name 

{ 

priváté get { return this.name; } // ez nem működik 
set { this.name = value; } 

} 

public string Name 

{ 

get { return this.name; } 

priváté set { this.name = value; }//ez viszont jó 

} 
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Arra is van lehetőség, hogy csak az egyiket használjuk, ekkor csak írható/olvasható tulajdonságokról beszélünk: 


public stning Name 

{ 

get { return this. name; } 

} 


Egyik esetben sem vagyunk rákényszerítve, hogy azonnal visszaadjuk/beolvassuk az adattag értékét, tetszés 
szerint végezhetünk műveleteket is rajtuk: 


public stning Name 
{ 

get { netunn "Mn. 

" + this. name; } 

} 



A C# 3.0 rendelkezik egy nagyon érdekes újítással, az ún. automatikus tulajdonságokkal. Nem kell létrehoznunk 
sem az adattagot, sem a teljes tulajdonságot, a fordító mindkettőt legenerálja nekünk: 


public stning Name 

{ 

get; 

set; 


A fordító automatikusan létrehoz egy priváté elérésű, string típusú, „name" nevű adattagot, és elkészíti hozzá a 
getter-t/setter-t is. Van azonban egy probléma, méghozzá az, hogy a fordítás pillanatában ez a változó még 
nem létezik, vagyis közvetlenül nem hivatkozhatunk rá pl. a konstruktorban. Ilyenkor a setter-en keresztül kell 
értéket adnunk. 


eláss Person 

{ 

public Penson(stning name) 

{ 

this. Name = name; 

} 

public stning Name 

{ 

get; 

set; 

} 

} 
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INDEXELŐK 


Az indexelők hasonlóak a tulajdonságokhoz, azzal a különbséggel, hogy nem névvel, hanem egy indexszel 
férünk hozzá az adott információhoz. Általában olyan esetekben használják, amikor az osztály/struktúra 
tartalmaz egy tömböt vagy valamilyen gyűjteményt (vagy olyan objektumot, amely maga is megvalósít egy 
indexeló't). Egy indexeló't így implementálhatunk: 


using System; 

using System.Collections; 

namespace TestApp 

{ 

eláss Names 

{ 

priváté ArrayList nameList; 

public Names() 

{ 

nameList = new ArrayList(); 
nameList.Add( "István") ; 
nameList.Add( "Szandra") ; 
nameList.Add("Béla"); 
nameList.Add( "Balázs") ; 

} 

public int Count 

{ 

get { return nameList.Count; } 

} 

public string this[int idx] 

{ 

get 

{ 

if (idx >= 0 && idx < nameList.Count) 

{ 

return nameList[idx] .ToStringQ; 

} 

return null; 

} 

} 

} 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

Names n = new Names(); 

fór (int i = 0; i < n.Count; ++i) 

{ 

Console.WriteLine(n[i]); 

} 

Console .ReadKey(); 

} 

} 

} 
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Ez gyakorlatilag egy „névtelen tulajdonság", a this mutat az aktuális objektumra, amin az indexeiét definiáltuk. 
Több indexet is megadhatunk, amelyek különböző típusú indexszel vagy visszatérési értékkel rendelkezhetnek. 
Nem csak egy paraméterrel hivatkozhatunk egy indexelővei, például ha a „belső" adatszerkezet egy 
kétdimenziós tömb, akkor ennek megfelelő mennyiségű paraméterrel dolgozhatunk: 


public int this[int idxx, int idxy] 

{ 

get 

{ 

/*...*/ 

} 

} 
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Statikus tagok 


A hagyományos adattagok és metódusok objektumszinten léteznek, azaz minden objektum minden 
adattagjából saját példánnyal rendelkezik. Gyakran van azonban szükségünk objektumtól független 
mezó'kre/metódusokra, pl. ha meg szeretnénk számolni, hogy hány objektumot hoztunk létre. Erre a célra 
szolgálnak az ún. statikus tagok, amelyekből osztályszinten összesen egy darab létezik. Statikus tagokat akkor is 
használhatunk, ha az osztályból nem készült példány. 

A statikus tagok jelentősége a C# nyelv tisztán objektum orientált mivoltában rejlik, ugyanis nem definiálhatunk 
globális (mindenki számára egyformán elérhető) tagokat. Ezt (is) váltják ki a statikus adattagok és metódusok. 


Statikus adattag 


Statikus tagot a static kulcsszó segítségével hozhatunk létre: 


using System; 

namespace TestApp 

{ 

eláss Animál 

{ 

static public int AnimalCounter = 0; 

public Animal() 

{ 

++Animal. AnimalCounter; 

} 

~Animal() 

{ 

--Animál. AnimalCounter; 

} 

} 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

Animál a = new Animal(); 

Console.WriteLine( Animál. AnimalCounter); 

Console .ReadKey(); 

} 

} 

} 


A példában a statikus adattag értékét minden alkalommal megnöveljük eggyel, amikor meghívjuk a 
konstruktőrt, és csökkentjük, amikor az objektum elpusztul, vagyis az aktív példányok számát tartjuk számon 
vele. 

A statikus tagokhoz az osztály nevén (és nem egy példányán) keresztül férünk hozzá (a statikus tag 
„gazdaosztályából" az osztály neve nélkül is hivatkozhatunk rájuk, de ez nem ajánlott, mivel rontja az 
olvashatóságot). 

A statikus tagok - ha az osztálynak nincs statikus konstruktora - rögtön a program elején inicializálódnak. Az 
olyan osztályok statikus tagjai, amelyek rendelkeznek statikus konstruktorral, az inicializálást elhalasztják addig 
a pontig, amikor először használjuk az adott osztály egy példányát. Konvenció szerint minden statikus tag 
(adattagok is) neve nagybetűvel kezdődik. A statikus és láthatósági módosító megadásának sorrendje 
tetszőleges. 
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Statikus konstruktőr 


A statikus konstruktőr a statikus tagok beállításáért felel. Közvetlenül azelőtt fut le, hogy egy példány keletkezik 
az adott osztályból, vagy hozzáfértek valamely tagjához. 

A statikus konstruktornak nem lehet láthatóságot adni, illetve nincsenek paraméterei sem. Nem férhet hozzá 
példánytagokhoz sem. 


using System; 

namespace TestApp 

{ 

eláss Test 

{ 

static public int Var = Test.Init(); 

static public int Init() 

{ 

Console.WriteLine("Var = 10"); 
return 10; 

} 

static Test() 

{ 

Console.WriteLine( "Statikus konstruktőr") ; 

} 

public Test() 

{ 

Console.WriteLine( "Konstruktőr") ; 

} 

} 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

Console.WriteLine("Start. .. "); 

Test t = new Test(); 

Console .ReadKey(); 

} 

} 

} 


Ha elindítjuk a programot, a következő kimenetet kapjuk: 


Start... 

Var = 10 

Statikus konstruktőr 
Konstruktőr 


A statikus konstruktoroknak van azonban egy hatalmas „hibájuk", amelyet a következő példában láthatunk: 
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eláss Program 

{ 

static void Main(string[] args) 

{ 

Stopwatch sw = Stopwatch.StartNew(); 

fór (int i = 0; i < 10000000; ++i) 

{ 

int x = Al.x; 

} 

Console.WriteLine( "Eltelt idő: {0}ms"j sw.ElapsedMilliseconds); 

sw = Stopwatch. StartNewQ; 

fór (int i = 0; i < 10000000; ++i) 

{ 

int x = A2.x; 

} 

Console.WriteLine( "Eltelt idő: {0}ms"j sw.ElapsedMilliseconds); 
Console. ReadKeyQ; 

} 

} 


A Stopwatch osztály a System.Diagnostics névtérben van, és - ahogyan látszik is - időt tudunk mérni vele. 


Mindkétszer tízmillió alkalommal kértük el a statikus tag értékét, lássuk az eredményt: 


Eltelt idő: 12ms 
Eltelt idő: 88ms 


A különbség elképesztően nagy, az ok pedig a következő: ha definiáltunk statikus konstruktőrt, akkor a rendszer 
minden egyes alkalommal, amikor statikus taghoz próbálunk hozzáférni, ellenőrzi, hogy meghívódott-e már, ez 
pedig a fenti teljesítményveszteséget eredményezi. 

Statikus metódus 

Statikus metódust a hagyományos metódusokhoz hasonlóan készítünk, mindössze a static kulcsszóra van 
szükségünk. Ilyen metódus volt az előző példában az Init metódus is. A statikus konstruktőrtől eltérően rá nem 
vonatkozik, hogy nem lehetnek paraméterei. Statikus metódusok nem férnek hozzá az osztály „normális" 
tagjaihoz, legalábbis direkt módon nem (az minden további nélkül működik, ha egy példány referenciáját adjuk 
át neki). 

Statikus metódust általában akkor használunk, ha nem egy példány állapotának a megváltoztatása a cél, hanem 
egy osztályhoz kapcsolódó művelet elvégzése. Ilyen metódus például az Int32 osztályhoz tartozó Parse statikus 
metódus is. 
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A „leghíresebb" statikus metódus a Main. 


Statikus tulajdonság 

A statikus tulajdonságok a C# egy viszonylag ritkán használt lehetősége. Általában osztályokhoz kapcsolódó 
konstans értékek lekérdezésére használjuk (lényegében a statikus metódusok egy olvashatóbb verziója). 


eláss Math 

{ 

static public double Pl 

{ 

get { netunn 3.14; } 

} 

} 


Statikus osztály 

Egy osztályt statikusnak jelölhetünk, ha csak és kizárólag statikus tagjai vannak. Egy statikus osztályból nem 
hozható létre példány, nem lehet példány-konstruktora (de statikus igen), és mindig lezárt (Id. Öröklődés). A 
fordító minden esetben ellenőrzi ezeknek a feltételeknek a teljesülését. 


static eláss MathHelpen 

{ 

static public double Pl 

{ 

get { netunn 3.14; } 

} 

static public double Cos(double x) 

{ 

netunn Math.Cos(x); 

} 
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Struktúrák 


A struktúrák - szerkezetüket tekintve - hasonlóak az osztályokhoz, viszont azoktól eltéró'en nem referencia-, 
hanem értéktípusok. 

Minden struktúra índirekt módon a System.ValueType osztályból származik. Ez egy speciális típus, amely 
lehetó'séget biztosít értéktípusok számára, hogy referenciatípusként viselkedjenek (lásd: Boxing). 

A struktúrák közvetlenül tartalmazzák a saját értékeiket, míg az osztályok „csak" referenciákat tárolnak. Épp 
ezért struktúrát általában akkor használunk, ha egyszerű adatokkal kell dolgoznunk, de nincs szükségünk egy 
osztály minden szolgáltatására. 


Konstruktőr 

Minden struktúra alapértelmezetten rendelkezik egy konstruktorszerűséggel (vigyázat, nem igazi konstruktőr), 
amely elvégzi a tagok nullára inicializálását (lényegében nullákkal tölti fel az adott memóriaterületet). Ez a 
lehetó'ség mindig él, nem rejthető el. 


using System; 

namespace TestApp 

{ 

struct Test 

{ 

public int x; 

} 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

Test t = new Test(); 

Console. WriteLine(t.x); // x == 0 

Console .ReadKey(); 

} 

} 

} 


Nem kötelező használni a new operátort, de ha így teszünk, akkor a struktúra tagjainak használata előtt 
definiálni kell az értéküket, ellenkező esetben a program nem fordul le: 


using System; 

namespace TestApp 

{ 

struct Test 

{ 

public int x; 

} 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Test t; 

Console. WriteLine(t.x); // nem jó, x inicializálatlan 
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Console .ReadKey(); 


} 


} 


} 


Készíthetünk saját konstruktőrt, de ekkor minden mező értékadásáról gondoskodnunk kell. Egy struktúra 
mezőit nem inicializálhatjuk: 


struct 

Test 


{ 





int 

x = 10; // ez 

nem jó 


int 

y; 



public Test(int x. 

int y) 


{ 





this.y = y j // 

ez sem jó, x nem kap értéket 


} 



} 





Struktúrában csakis paraméteres konstruktőrt definiálhatunk, paraméter nélküli alapértelmezettet nem. 
Viszont ha ezt megtettük, attól az alapértelmezett konstruktőr még használható marad: 


using System; 


namespace TestApp 
{ 

struct Test 

{ 

int x; 
int y; 


public Test(int x, int y) 

{ 

this.y = y; 
this.x = x; 

} 

} 


eláss Program 
{ 

static void Main(string[] 

{ 

Test ti = new Test(10, 
Test t2 = new Test(); 

args) 

11); 

//ez is működik 

Console .ReadKey(); 

} 

} 

} 



Destruktor 

Struktúrák nem rendelkezhetnek destruktorral. Egy struktúra két helyen lehet a memóriában: a stack-ben és a 
heap-ben (ha egy referenciatípus tagja). 

Ahhoz, hogy megértsük, hogy miért nincs destruktor, szükségünk van a következőre: egy struktúrában lévő 
referenciatípusnak csak a referenciáját tároljuk. Ha a veremben van a struktúra, akkor előbb vagy utóbb kikerül 
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onnan, és mivel így a benne lévő referenciatípusra már nem mutat referencia (legalábbis a struktúrából nem), 
ezért eltakarítható. Ugyanez a történet akkor is, ha a struktúra példány egy referenciatípusban foglal helyet. 


Adattagok 

A struktúrák az adattagokat közvetlenül tárolják (míg osztályok esetében mindig referenciákat tartunk számon). 
Egy struktúra minden adattagja - amennyiben a konstruktorban nem adunk meg mást - automatikusan a 
megfelelő nulla értékre inicializálódik. 

Struktúra nem tartalmazhat saját magával megegyező típusú adattagot. Ugyanígy, egy struktúra nem 
tartalmazhat olyan típusú tagot, amely típus hivatkozik az eredeti struktúrára: 


struct Test 

{ 

Test t; 

} 

struct Testi 

{ 

Test2 t; 

} 

struct Test2 

{ 

Testi t; 

} 


Mindhárom struktúra hibás. Az ok nagyon egyszerű: mivel a struktúrák direkt módon - nem referenciákon 
keresztül - tárolják az adattagjaikat, valamint mivel a struktúrák nem vehetnek fel null értéket, a fenti 
szerkezetek mind végtelen hurkot (és végtelen memóriafoglalást) okoznának (Testi struktúra, amiben Test2, 
amiben Testi és így tovább) (lásd: tranzitív lezárt). 


Hozzárendelés 


Amikor egy struktúra példánynak egy másik példányt adunk értékül, akkor egy teljesen új objektum keletkezik: 


using System; 

namespace TestApp 

{ 

struct Test 

{ 

public int x; 

} 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

Test ti = new Test(); 

Test t2 = ti; 
t2.x = 10; 

Console.WriteLine("tl.x = {0}., t2.x = {1}", tl.x, t2.x); 
Console . ReadKey(); 

} 

} 

} 
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Ha lefordítjuk ezt a kódot, azt fogjuk látni, hogy tl.x értéke nem változott, tehát nem referenciát adtunk át t2- 
nek. 

Most nézzünk meg egy nagyon gyakori hibát, amibe belefuthatunk! Adott a következő programkód: 


using System; 

namespace TestApp 

{ 

struct Point 

{ 

int x; 

public int X 

{ 

get { return x; } 
set { x = value; } 

} 

int y; 

public int Y 

{ 

get { return y; } 
set { y = value; } 

} 

public Point(int x, int y) 

{ 

this.x = x; 
this.y = y; 

} 

} 

struct Line 

{ 

Point a; 
public Point A 
{ 

get { return a; } 
set { a = value; } 

} 

Point b; 
public Point B 
{ 

get { return b; } 
set { b = value; } 

} 

} 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

Line 1 = new Line(); 

1.A = new Point(10j 10); 
l.B = new Point(20, 20); 

Console .ReadKey(); 

} 

} 

} 
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Teljesen szabályos forrás, le is fordul. Látható, hogy a Point struktúra publikus tulajdonságokkal bír, vagyis 
jogosnak tűnik, hogy a Line struktúrán keresztül módosítani tudjuk a koordinátákat. Egészítsük ki a kódot: 


Line 1 = new Line(); 
l.A = new Point(10j 10); 
l.B = new Point(20j 20); 
l.A.X = 5; 


Ez a forráskód nem fog lefordulni, mivel nem változónak akarunk értéket adni. Mi lehet a hiba oka? A probléma 
ott van, hogy rosszul értelmeztük ezt a kifejezést. Az l.A valójában a getter-t hívja meg, ami az eredeti struktúra 
egy másolatával tér vissza, amelynek a tagjait módosítani viszont nincs értelme. Ilyen esetekben mindig új 
struktúrát kell készítenünk: 


Line 1 = new Line(); 
l.A = new Point(10j 10); 
l.B = new Point(20, 20); 
l.A = new Point(5, 10); 


Öröklődés 

Struktúrák számára az örökló'dés tiltott, minden struktúra automatikusan sealed módosítót kap. Ilyen módon 
egy struktúra nem lehet absztrakt, tagjainak elérhetó'sége nem lehet protected/protected internál, metódusai 
nem lehetnek virtuálisak, illetve csak a System.ValueType metódusait definiálhatja át. Ez utóbbi esetben a 
metódushívások nem járnak bedobozolással: 


struct Test 

{ 

public int x; 

public override stning ToString() 

{ 

return "X == " + x.ToString(); 

} 

} 
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Osztálykönyvtárak 


Eddig mindig egyetlen projektben dolgoztunk, ennek viszont megvan az a hátránya, hogy a program 
növekedésével együtt a forráskód is több helyet foglal. Hozzá kell tennünk azt is, hogy ez a fajta megközelítés a 
kód-újrafelhasználást is rontja, hiszen az általánosabb programrészeket minden új projektbe ismét be kellene 
másolni. Sokkal egyszerűbb lenne a dolgunk, ha az újrahasznosítandó forráskódot külön tudnánk választani a 
tényleges programtól, ezzel idó't és helyet takarítva meg. Erre a célra találták ki a shared library (~megosztott 
könyvtár) fogalmát, amely a Windows alapú rendszereken a DLL -t (Dynamic Link Library) jelenti. 

A DLL könyvtárak felépítése a használt fejlesztői platformtól függ, tehát egy COM DLL nem használható 
közvetlenül egy .NET programban. .Net környezetben egy ilyen könyvtárat assemblynek nevezünk. 

Készítsük el az első osztálykönyvtárunkat! Feltesszük, hogy Visaul Studio-ban már elkészítettünk egy Console 
Application típusú projektet. Kattintsunk jobb gombbal a Solution-ön, és az Add menüből válasszuk a New 
Project elemet: 


b«=»H3H 





Solution Explorer 

» ? x| 




ÉSÉ Build Solution 
Rebuild Solution 


F6 


Add 

► 

Set StartUp Projects... 


^ r 3ST0 

Rename 

Ctrl+V 

!!(2l Properties 

Alt+Enter 


stApp 

Properties 

Pefcrcrtrcr 

New Project... 
Existing Project... 


A megjelenő ablakban a Class Library sablont kell használnunk: 
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Add New Project 


Name: MyLibrary 

Location: C:\Users\Reiter\documents\visual stúdió 2010\Projects\TestApp2 


Recent Templates 

Sort by: 

Default ▼ llüiiü [:||| 



Search Installed Templates fi | 

Installed Templates 






V 



- 

Type: Visual C# 

a Visual C# 

MwmLight (WP71) 

Visual C# 



A project fór creating a C# class library 

Silverlight fór Windows Phone 
XNA Game Stúdió 4.0 

jg*] 

Windows Forms Application 

Visual C# 


(■dili 

Online Templates 

□fi 

WPF Application 

Visual C# 




m 

Console Application 

Visual C# 





Class Library 

Visual C# 

= 



fal 

WPF Browser Application 

Visual C# 




feÜl 

Empty Project 

Visual C# 




m 

Windows Game (4.0) 

Visual C# 





Windows Game Library (4.0) 

Visual C# 





Xbox 360 Game (4.0) 

Visual C# 




,31 

Xbox 360 Game Library (4.0) 

Visual C# 

* 




Az OK gombra kattintva elkészül az új projekt. Egyelőre csak egy osztályt tartalmaz, viszont Main függvényt 
nem, így ezt a projektet nem lehet futtatni, csakis egy másik projektből hívhatjuk meg a szolgáltatásait. 
Készítsünk egy egyszerű osztályt, akár átnevezve a már létezőt, akár újat létrehozva! 


using System; 

namespace MyLibrary 

{ 

public eláss ClassLib 

{ 

static public void PrintHello() 

{ 

Console.WriteLine("Én egy osztálykönyvtárban vagyok!"); 

} 

} 

} 


A következő lépésben tudatnunk kell a „fő" projekttel, hogy van egy osztálykönyvtárunk. A projekten belül ott 
van egy References nevű könyvtár, amely a felhasznált könyvtárakat tárolja. Kattintsunk rajta jobb gombbal, és 
válasszuk az Add Reference pontot: 
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-i I *3 Jí i3 x- fi ^ l3 * 5 



Solution Explorer w ? X 

®l I í2> J] 

^ Solution 'TestApp' (2 projects) 

4 ijp] MyLibrary 

> £y| Properties 

> References 
ClassLib.es 

d ^ TestApp 

> gj| Properties 


Add Reference... 

Add Service Reference.. 


■ices 

m.cs 


Az Add Reference ablakban, a Projects fülön megjelennek a Solution-ben szereplő projektek, válasszuk az előbb 
elkészített könyvtárat: 



Az OK gombra kattintva a projeetben felhasználhatjuk az osztálykönyvtár szolgáltatásait. A hivatkozott könyvtár 
a fordítás után a célkönyvtár futtatható állománya mellé kerül .dll kiterjesztéssel, ha tovább akarjuk adni 
programunkat, azt is mellé kell másolnunk. 

A forráskódban a névtér megadása után azonnal kapunk Intellisense támogatást is. Készítsük egy programot, 
amely felhasználja az osztálykönyvtárunkat: 
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using System; 

using MyLibrary; // az osztálykönyvtár névtere 

namespace TestApp 

{ 

eláss Program 

{ 

static public void Main(string[ ] args) 

{ 

ClassLib.PrintHello(); 

Console .ReadKey(); 

} 

} 

} 
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Gyakorló feladatok III. 


Faktoriális és hatvány 

Készítsünk rekurzív faktoriális és hatványt számító függvényeket! 

Megoldás (19/RecFact.cs és 19/RecPow.cs) 

Mi is az a rekurzív függvény? Egy függvény, amely önmagát hívja. Rengeteg olyan probléma van, amelyeket 
több, lényegében azonos feladatot végrehajtó részre lehet osztani. Vegyük pl. a hatványozást: semmi mást nem 
teszünk, mint meghatározott számú szorzást végzünk, méghozzá ugyanazzal a számmal. írhatunk persze egy 
egyszerű ciklust is, de ez egy kicsit „atombombával egérre" típusú megoldás lenne. Nézzük meg a hatványozás 
rekurzív megfeleló'jét: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static public double Pow(double x, int y) 

{ 

if (y == 0) { return 1.0; } 
else return x * Pow(x, y - 1); 

} 

static void Main(string[] args) 

{ 

double result = Pow(2, 10); 
Console.WriteLine(result); // 1024 

Console .ReadKey(); 

} 

} 

} 


Látható, hogy x-et (az alapot) érintetlenül hagyjuk, míg a kitevó't (y) a függvény minden hívásakor eggyel 
csökkentjük, egészen addig, amíg értéke nulla nem lesz. Ekkor befejezzük az „ördögi" kört, és visszaadjuk az 
eredményt. 

Hasonlóképpen készíthetjük el a faktoriálist számoló programot is: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static public int Fact(int x) 

{ 

if (x == 0) { return 1; } 
else return x * Fact(x - 1); 

} 

static void Main(string[ ] args) 

{ 

int result = Fact(10); 
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} 


} 


Console.WriteLine(result); 
Console .ReadKey(); 


Gyorsrendezés 


Valósítsuk meg a gyorsrendezést! 

Megoldás (19/QuickSort.cs) 

A gyorsrendezés a leggyorsabb rendező' algoritmus, nagy elemszám esetén 0(n*logn) nagyságrendű átlaggal. 
Az algoritmus lényege, hogy a rendezendő elemek közül kiválaszt egy ún. pivot elemet, amely elé a nála 
nagyobb, mögé pedig a nála kisebb elemeket teszi, majd az így kapott két csoportra ismét meghívja a 
gyorsrendezést (tehát egy rekurzív algoritmusról beszélünk). Lássuk, hogy hogyan is néz ez ki a gyakorlatban! 


Nagy elemszámnál ugyan jól teljesít ez az algoritmus, de kevés elem esetén fordul a kocka. Éppen ezért amikor 
a rendezésre átadott tömbrészlet kellően kicsi, akkor egy általánosabb rendezést, pl. buborékrendezést 
érdemes használni. 


A legtöbb programozási nyelv „beépített" rendezései általában a gyorsrendezés egy variációját használják. 


eláss Arnay 

{ 

priváté int[] array; 

public Array(int length) 

{ 

array = new int[length]; 

} 

public int this[int idx] 

{ 

get { return array[idx]; } 
set { array[idx] = value; } 

} 

public int Length 

{ 

get { return array.Length; } 

} 

public void Sort() 

{ 

QuickSort(0j array.Length - 1); 

} 

priváté void QuickSort(int left, int right) 

{ 

// rendezés... 

} 

} 


Készítettünk egy osztályt, amely reprezentálja a rendezendő tömböt. A Sort metódussal fogjuk meghívni a 
tényleges rendező metódust, amely két paramétert kap, a rendezésre kiválasztott tömbrészlet alsó és felső 
indexét. A metódus implementációja a következó'képpen néz ki: 
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priváté void QuickSort(int left, int right) 

{ 

int pivot = array[left]; 
int lhold = left; 
int rhold = right; 

while (left < right) 

{ 

while (array[right] >= pivot && left < right) 

{ 

--right; 

} 

if (left != right) 

{ 

array[left] = array[right]; 

++left; 

} 

while (array[left] <= pivot && left < right) 

{ 

++left; 

} 

if (left != right) 

{ 

array[right] = array[left]; 

--right; 

} 


array[left] = pivot; 
pivot = left; 
left = lhold; 
right = rhold; 

if (left < pivot) 

{ 

QuickSort(left, pivot - 1); 

} 

if (right > pivot) 

{ 

QuickSort(pivot + 1 , right); 

} 

} 


A tömb mindkét oldaláról behatároljuk a kisebb/nagyobb elemeket, majd továbbhívjuk a rendezést. Nézzük 
meg az algoritmus működését egy példán keresztül! A rendezendő számsorozat legyen: 

3, 9, 4, 6, 8,11 

Left és right 0 és 5 (ugye hat elem van a tömbben, és nullától indexelünk), ezeket az értékeket eltároljuk, mivel 
az értékük módosulni fog, de a metódus végén szükség van az eredetiekre. 

Az első ciklus - mivel nem fog a left indexen lévő számnál (3) kisebbet találni - úgy végződik, hogy right értéke 
0 lesz. Az elágazásba - mivel right és left egyenlő - nem megyünk bele, ugyanúgy, ahogyan a második ciklusba 
sem, mivel a hármasnál kisebb elem nincs, a nála nagyobbak pedig utána helyezkednek el. A következő 
elágazás szintén kimarad, és nekiállhatunk kiszámolni, hogy miként hívjuk meg újra a metódust. A tömb 
változatlan marad, a pivot változó nulla értéket kap, right és left pedig visszakapják az eredeti értéküket. 
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Ezután a második elágazást fogjuk használni (ne feledjük, hogy right értéke ismét 5), és meghívjuk a QuickSort 
metódust 1 illetve 5 paraméterekkel, vagyis az első elemet (3) - mivel ő már a helyén van - átugorjuk. 

Következik a második forduló, a pivot változó értéke most kilenc lesz, míg left és right értéke 1 és 5. Az első 
ciklus egyszer fog lefutni, hiszen a tömb negyedik indexén ülő nyolcas szám már kisebb mint a pivot elem. Left 
nem egyenlő right -tál ezért a következő elágazásba is bemegyünk, és a left indexre helyezzük a right indexen 
lévő nyolcast (a pivot elem pedig pont az itt „már nem" lévő kilencest tárolja). Left előrelép eggyel, hogy a 
tömb második indexére (4) mutasson. 

A második ciklus is lefut, egészen addig fogjuk növelni left értékét, amíg eléri a right által mutatott nyolcast, 
hiszen ott a ciklus feltétel második fele sérül. Most left és right értéke egyenlő: 4. Éppen ezért a második 
elágazást kihagyjuk és továbblépünk. A left által mutatott indexre behelyezzük a pivotban lévő kilencest, amivel 
helyre is áll a rend. Pivot értéke ezután négy lesz és a két másik változó is visszakapja az értékét. Left kisebb 
most, mint a pivot és right pedig nagyobb nála, így mindkét elágazás feltétele teljesül, vagyis most mindkét 
oldalra hívjuk a metódust. 

Az ezutáni események átgondolása pedig az olvasó feladata. 


Láncolt lista 


Valósítsuk meg a láncolt lista adatszerkezetet! 


Megoldás (19/LinkedList.cs) 

Amikor tömbökkel dolgozunk, akkor a tömb elemeit indexekkel érjük el. A láncolt lista olyan adatszerkezet, 
amelynek elemei a soron következő elemre hivatkozó referenciát tartalmaznak. A láncolt listát az első fej- vagy 
gyökérelemen keresztül érjük el. Ha az elemek csak a következő tagra mutatnak, akkor egyszeresen, ha a 
megelőző elemre is, akkor kétszeresen láncolt listáról beszélünk: 

□—tn—□ i i- ’i i- ’i—i 

Elsőként valósítsuk meg az elemeket jelképező osztályt: 


eláss Node 

{ 

public Node(int value) 

{ 

this. Value = value; 

} 

public int Value{ get; set; } 

public Node Next{ get; set; } 
public Node Previous { get; set; } 

} 


Most pedig jöjjön a láncolt lista osztály: 


eláss LinkedList 

{ 

public LinkedList() { } 

public LinkedList(int[] values) 

{ 

foreach (int value in values) 

{ 

this .Add(value); 

} 
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} 

public void Add(int value) 

{ 

if (Root == null) 

{ 

Root = new Node( value); 

} 

else 

{ 

Node current = Root; 
while (current.Next != null) 

{ 

current = current.Next; 

} 

current.Next = new Node(value); 
current.Next.Previous = current; 

} 

} 

public Node Root { get; priváté set; } 


Az Add metódus az, amelyik számunkra érdekes. Elsőként megvizsgáljuk, hogy létezik-e gyökérelem, ha nem, 
akkor létrehozzuk, és nincs is más dolgunk (ugye ilyenkor még nincs se előző, se rákövetkező elem). Más a 
helyzet, ha van már néhány elem a listában, ekkor meg kell keresnünk a legutolsó elemet, és utánafűzni az újat 
(megvalósíthattuk volna úgy is a listát, hogy tárolunk egy referenciát az utolsó elemre, ez lényegesen gyorsabb 
lenne - de kevésbé érdekes). 

Ahhoz, hogy megkeressük az utolsó elemet, szükségünk lesz egy átmeneti referenciára, amely mindig az 
aktuális elemet mutatja majd. A ciklust addig kell futtatni, ameddig az aktuális elem rákövetkezője null értékre 
nem mutat, ekkor beállítjuk a Next és Previous értékeket is. 


Bináris keresőfa 

Készítsünk bináris keresőfát! 

Megoldás (19/BinaryTree.cs) 

A fa típus olyan adatszerkezet, amelynek elemei nulla vagy több gyermekelemmel és maximum egy 
szülőelemmel rendelkeznek: 



A képen az A elem gyermekei B illetve C, akiknek természetesen A lesz a közös szülőelemük. A fa típus egy 
speciális esete a bináris fa, amely minden elemének pontosan egy szülő és maximum kettő gyermek eleme 
lehet. A bináris fa speciális esete pedig a bináris keresőfa, amelynek jellemzője, hogy egy szülő elem bal oldali 
részfájában a szülőelemnél kisebb, jobb oldali részfájában pedig a szülőelemnél nagyobb elemek vannak, 
ezáltal egyértelműen meghatározható, hogy egy elem benne van-e a fában vagy nincs (értelemszerűen a 
részfák is keresőfák, vagyis rájuk is ugyanez vonatkozik). A bináris keresőfa minden elemének egyedi kulccsal 
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kell rendelkeznie, vagyis ugyanaz az elem kétszer nem szerepelhet a fában. A keresés művelet O(logn) 
nagyságrendű. 

Ahogyan az előző feladatban, most is kezdjük a fa csúcsait jelképező osztállyal: 


eláss TreeNode 

{ 

public TneeNode(int value) 

{ 

this. Value = value; 

} 

public int Value { get; set; } 

public TreeNode Parent { get; set; } 
public TreeNode Left { get; set; } 
public TreeNode Right { get; set; } 

} 


Most pedig készítsük el a fa osztályt! 


eláss BinaryTree 

{ 

public BinaryTree() { } 

public BinaryTree(int[] values) 

{ 

foreach (int value in values) 

{ 

this .Insert(value); 

} 

} 

public void Insert(int value) { } 
public TreeNode Root { get; priváté set; } 

} 


Az osztály váza hasonlít a láncolt listáéhoz, itt is szükségünk van egy gyökérelemre, ez tulajdonképpen a legelső 
beszúrt csúcs lesz. 

írjuk meg a hiányzó Insert metódust: 


public void Insert(int value) 

{ 

if (Root == null) 

{ 

Root = new TreeNode(value); 

} 

else 

{ 

TreeNode current = Root; 

while (current != null) 

{ 

if (current.Value > value) 

{ 

if (current.Left == null) 

{ 

current.Left = new TreeNode(value); 
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current.Left.Parent = current; 
return; 

} 

else 

{ 

current = current.Left; 

} 

} 

else if (current.Value < value) 

{ 

if (current.Right == null) 

{ 

current.Right = new TreeNode(value) ; 
current.Right.Parent = current; 
return; 

} 

else 

{ 

current = current.Right; 

} 

} 

else return; 

} 

} 

} 


Ha a gyökérelem null értéken áll, akkor készítünk egy új TreeNode objektumot, egyébként megkeressük az új 
elem helyét oly módon, hogy minden csúcsnál a megfelelő irányba „fordulunk". Amennyiben az adott érték 
már szerepel a fában, egyszerűen elhagyjuk a ciklust. Tegyük fel, hogy az elemek a következő sorrendben 
érkeznek: 

10, 1, 4, 6, 6, 3, 9, 12 

Ekkor a bináris keresőfa így fog kinézni: 



A következő feladatunk, hogy kiírjuk a fa elemeit a konzolra. Persze ez nem is olyan egyszerű, hiszen megfelelő 
algoritmusra lesz szükségünk ahhoz, hogy a fa elemeit bejárhassuk. Egy rekurzív algoritmust fogunk használni, 
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amely stratégiától függó'en az egyes csúcsok részfáit, majd magát a csúcsot látogatja meg. Háromféle stratégiát 
ismerünk: preorder, inorder és postorder. A preorder elsőként a csúcsot, majd a bal és jobb oldali részfát veszi 
kezelésbe. Inorder módon a bal oldali részfa, a csúcs és a jobb oldali részfa lesz a sorrend, végül pedig a 
postorder bejárás sorrendje a bal oldali részfa, a jobb oldali részfa, végül pedig a csúcs. Nézzük meg, hogyan is 
működik mindez a gyakorlatban! A fent felépített fán fogunk inorder módon végigmenni. 

Az algoritmust a gyökérelemre (10) fogjuk meghívni, amely elsőként a bal oldali részfa csúcsát (1) fogja 
meglátogatni. Mivel neki nincsen bal oldali részfája, ezért kiírjuk az egyes számot, és lépünk a jobb oldali 
részfára (4). Neki már van bal oldali ága, ezért őt vizsgáljuk a továbbiakban. Itt nincs gyermekelem, ezért a 
következő szám, amit kiírhatunk, a három. Visszalépünk a szülőelemre, és kiírjuk őt (4), majd lépünk jobbra. A 
hatos csúcsnak sincs bal oldali fája, ezért kiírjuk, majd jön a jobb fában a kilences, amit megint csak kiírunk, 
hiszen nem rendelkezik gyermekelemmel. 

Ezen a ponton végeztünk a gyökérelem bal oldali fájával, ezért őt jelenítjük meg, ezután pedig már csak 
egyetlen elem marad. A végső sorrend tehát: 

1, 3, 4, 6, 9,10,12 

A forráskódban ez az algoritmus meglehetősen egyszerűen jelenik meg, következzen az inorder bejárás: 


public void InOrder(Action<int> action) 

{ 

_inOrden(Rootj action); 

} 

priváté void _inOrder(TreeNode root, Action<int> action) 

{ 

if (root == null) { return; } 

_inOrder(root.Left, action); 
action(root.Value); 

_inOrder(root.Right, action); 

} 


Az Action<T> osztályról a Lambda kifejezések c. fejezetben olvashat többet az olvasó. 
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Öröklődés 


Öröklődéssel egy már létező típust terjeszthetünk ki vagy bővíthetjük tetszőleges szolgáltatással. A C# csakis 
egyszeres öröklődést engedélyez, vagyis minden osztály egyetlen ősosztályból származhat (leszámítva a 
System. Object-et), ugyanakkor megengedi több interfész implementálását (interfészekről hamarosan). 

Készítsük el az elméleti rész példáját (Állat-Kutya-Krokodil) C# nyelven! Az egyszerűség kedvéért hagyjuk ki az 
Állat és Kutya közti speciálisabb osztályokat: 


eláss Animál 

{ 

} 

eláss Dog : Animál 

{ 

} 

eláss Crocodile : Animál 

{ 

} 


Az ősosztályt az osztálydeklaráció után írt kettőspont mögé kell írni, szintén itt lesznek majd az osztály által 
megvalósított interfészek is. 

A Kutya és Krokodil osztályok egyaránt megvalósítják az ősosztály (egyelőre szegényes) funkcionalitását. 
Bővítsük hát ki: 


eláss Animál 

{ 

public Animal(string name) 

{ 

this.Name = name; 

} 

public string Name { get; set; } 

public void Eat() 

{ 

Console.WniteLine( "Hamm - Hamm"); 

} 

} 


Vegyük észre, hogy paraméteres konstruktőrt készítettünk az ősosztálynak, vagyis át kell gondolnunk a 
példányosítást! Az első változatot (az alapértelmezett konstruktorral) így használhattuk: 


Dog d = new Dog(); 

Crocodile c = new CrocodileQ; 


Ha ezt az új Animál osztállyal próbáljuk meg akkor meglepetés fog érni, mivel nem fordul le a program. Ahhoz, 
hogy ki tudjuk javítani a hibát, tudnunk kell, hogy a leszármazott osztályok először mindig a közvetlen ősosztály 
konstruktőrét hívják meg, vagyis - ha nem adunk meg mást - az alapértelmezett konstruktőrt. A probléma az, 
hogy az ősosztálynak már nincs ilyenje, ezért a leszármazott osztályokban explicit módon hívni kell a megfelelő 
konstruktőrt: 
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eláss Dog : Animál 

{ 

public Dog(string name) 

: base(name) 

{ 

} 

} 

eláss Crocodile : Animál 

{ 

public Crocodile(string name) 
: base(name) 

{ 

} 

} 


Ezután így példányosftunk: 


Dog d = new Dog("Füli"); 

Crocodile c = new Crocodile("Aladár"); 


Ugyanígy használhatjuk az ősosztály metódusát is: 


Dog d = new Dog("Füli"); 

Crocodile c = new Crocodile("Aladár"); 

d.Eat(); 

c.Eat()j 


Honnan tudja vajon a fordító, hogy egy ősosztálybeli metódust kell meghívnia? A referenciatípusok speciális 
módon jelennek meg a memóriában, rendelkeznek többek közt egy ún. metódus-táblával, ami mutatja, hogy az 
egyes metódushívásoknál melyik metódust kell meghívni. Persze ezt is meg kell határozni valahogy, ez nagy 
vonalakban úgy történik, hogy a fordító a fordítás pillanatában megkapja a metódus nevét, és elindul 
„visszafelé" az osztályhierarchia mentén. A fenti példában a hívó osztály nem rendelkezik Eat nevű metódussal, 
és nem is definiálja át annak a viselkedését (erről hamarosan), ezért az eggyel feljebbi őst kell megnéznünk. Ez 
egészen a lehető „legújabb" metódusdefinícióig megy, és amikor megtalálja a megfelelő implementációt, 
bejegyzi azt a metódustáblába. 


Virtuális metódusok 

Az ősosztályban deklarált virtuális (vagy polimorfikus) metódusok viselkedését a leszármazottak 
átdefiniálhatják. Virtuális metódust a szignatúra elé írt Virtual kulcsszó segítségével deklarálhatunk: 


using System; 


namespace TestApp 
{ 

eláss Animál 

{ 

public Virtual void Eat() 

{ 

Console.WriteLine("Egy állat eszik.. 

} 

} 

• "); 

eláss Dog : Animál 
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{ 

public override void Eat() 

{ 

Console. WriteLine("Kutya csontot rág..."); 

} 

} 

eláss Crocodile : Animál 

{ 

public override void Eat() 

{ 

Console.WriteLine("Krokodil embert rág..."); 

} 

} 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

Animál a = new Animal(); 

Dog d = new Dog(); 

Crocodile c = new Crocodile(); 

a.Eat(); 

d.Eat(); 

c.Eat(); 

Console .ReadKey(); 

} 

} 

} 


A leszármazott osztályokban az override kulcsszóval mondjuk meg a fordítónak, hogy szándékosan hoztunk 
létre az ősosztályéval azonos szignatúrájú metódust, és a leszármazott osztályon ezt kívánjuk használni 
mostantól. Egy override-dal jelölt metódus automatikusan virtuális is lesz, így az ő leszármazottai is 
átdefiniálhatják a működését: 


eláss Crocodile : Animál 

{ 

public override void Eat() 

{ 

Console. WriteLine( "Krokodil embert rág..."); 

} 

} 

eláss BigEvilCrocodile : Crocodile 

{ 

public override void Eat() 

{ 

Console. WriteLine( "Krokodil óceánjárót rág..."); 

} 

} 


Az utódosztály metódusának szignatúrája és láthatósága meg kell egyezzen azzal, amit át akarunk definiálni. 

Tegyük fel, hogy nem ismerjük az ősosztály felületét, és a hagyományos módon deklaráljuk az Eat metódust 
(ugye nem tudjuk, hogy már létezik)! Ekkor a program ugyan lefordul, de a fordító figyelmeztet minket, hogy 
eltakarjuk az öröklött metódust. És valóban, ha meghívnánk, akkor az új metódus futna le. Ezt a jelenséget 
árnyékolásnak (shadow) nevezik. 
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Természetesen mi azt szeretnénk, ha a fordítás hiba nélkül menne végbe, így tájékoztatnunk kell a fordítót, 
hogy szándékosan takarjuk el az eredeti implementációt. Ezt a new kulcsszóval tehetjük meg: 


eláss Animál 

{ 

public vintual void Eat() 

{ 

Console.WniteLine( "Egy állat eszik..."); 

} 

} 

eláss Dog : Animál 

{ 

public new void Eat() 

{ 

Console.WniteLine( "Kutya csontot rág..."); 

} 

} 


Ezután a Dog utódjai már nem látják az eredeti Eat metódust. Viszont készíthetünk beló'le virtuális metódust, 
amelyet az utódai már kedvükre használhatnak. Azaz, a new módosítóval ellátott metódus új sort kezd, amikor 
a fordító felépíti a metódustáblát, vagyis a new Virtual kulcsszavakkal ellátott metódus lesz az új 
metódussorozat gyökere. 


eláss Dog : Animál 
{ 

public new vintual void Eat() 

{ 


Console.WriteLine( "Kutya csontot rág.. 

} 

} 



Nem jelölhetünk virtuálisnak statikus, absztrakt és override-dal jelölt tagokat (az utolsó kettő' egyébként 
virtuális is lesz, de ezt nem kell külön jelölni). 


Polimorfizmus 

Korábban már beszéltünk arról, hogy az ős és leszármazottak közt az-egy (is-a) reláció áll fenn. Ez a 
gyakorlatban azt jelenti, hogy minden olyan helyen, ahol egy őstípust használunk, ott használhatunk 
leszármazottat is (pl. egy állatkertben állatok vannak, de az állatok helyére (nyilván) behelyettesíthetek egy 
speciálisabb fajt). Például gond nélkül írhatom a következőt: 


Animál d = new Dog("Füli"); 


A new operátor meghívása után d úgy fog viselkedni, mint a Dog osztály egy példánya (elvégre az is lesz), 
használhatja annak metódusait, adattagjait. Arra azonban figyeljünk, hogy ez visszafelé nem működik, a fordító 
hibát jelezne! 


Abban az esetben ugyanis, ha a fordító engedné a visszafelé konverziót, az ún. leszeletelődés (slicing) effektus 
lépne fel, azaz az adott objektum elveszítené a speciálisabb osztályra jellemző karakterisztikáját. A C++ 
nyelvben sokszor jelent gondot ez a probléma, mivel ott egy pointeren keresztül megtehető a „lebutítás". 
Szerencsére a C# nyelvben ezt megoldották, így nem kell aggódnunk miatta. 


Mi történik vajon a következő esetben: 


Animal[] animalArray = new Animal[2]; 
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animalArray[0] = new Animal(); 
animalArray[1] = new Dog(); 

animalArray[0].Eat(); 
animalArray[1].Eat(); 


Amit a fordító lát az az, hogy készítettünk egy Animál típusú elemekből álló tömböt és hogy az elemein 
meghívtuk az Eat metódust. Csakhogy az Eat virtuális metódus, ráadásul van leszármazottbeli implementációja 
is, amely átdefiniálja az eredeti viselkedést, és ezt explicit jelöltük is az override kulcsszóval. így a fordító fel 
tudja ismerni a futásidejű típust, és ezáltal ütemezi a metódushívásokat. Ez az ún. késői kötés (laté binding). A 
kimenet így már nem lehet kétséges. 

Már beszéltünk arról, hogyan épül fel a metódustábla, a fordító megkeresi a legkorábbi implementációt, és 
most már azt is tudjuk, hogy az első ilyen implementáció egy virtuális metódus lesz, azaz a keresés legkésőbb az 
első virtuális változatnál megáll. 


Lezárt osztályok és metódusok 


Egy osztályt lezárhatunk, azaz megtilthatjuk, hogy új osztályt származtassunk belőle: 


sealed eláss Dobermann : Dog 

{ 

} 

eláss MyDobermann : Dobermann // ez nem jó 

{ 

} 


Ebben az esetben az IntelliSense eleve fel sem ajánlja az osztályt. 

Egy metódust is deklarálhatunk lezártként, ekkor a leszármazottak már nem definiálhatják át a működését: 


eláss Dog : Animál 

{ 

public sealed override void Eat() 

{ 

Console.WriteLine( "Vau - Vau - Hamm - Hamm"); 

} 

} 

sealed eláss Dobermann : Dog 

{ 

public override void Eat() // ez sem jó 

{ 

} 

} 


Absztrakt osztályok 

Egy absztrakt osztályt nem lehet példányosítani. A létrehozásának célja az, hogy közös felületet biztosítsunk a 
leszármazottainak: 
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using System; 


namespace TestApp 
{ 

abstract eláss Animál 

{ 

abstract public void Eat(); 

} 


eláss Dog : Animál 
{ 

public override void Eat() 

{ 

Console.WriteLine("Kutya eszik.. 

} 

} 


eláss Program 
{ 

static void Main(string[] args) 

{ 

// Animál a = new AnimalQ; //ez 

nem fordul le 

Dog d = new Dog(); 
d.Eat(); 


Console .ReadKey(); 

} 

} 

} 



Látható, hogy mind az osztály, mind a metódus absztraktként lett deklarálva, ugyanakkor a metódus (látszólag) 
nem virtuális és nincs definíciója. 

Egy absztrakt osztály csak a fordítás közben absztrakt, a lefordított kódban teljesen normális osztályként 
szerepel, virtuális metódusokkal. A fordító feladata az, hogy betartassa a rá vonatkozó szabályokat, amelyek a 
következó'k: 

• absztrakt osztályt nem lehet példányosítani, 

• absztrakt metódusnak nem lehet definíciója, 

• a leszármazottaknak definiálnia kell az öröklött absztrakt metódusokat. 

Absztrakt osztály tartalmazhat nem absztrakt metódusokat is, ezek pont úgy viselkednek, mint a hagyományos 
nem-virtuális társaik. Az öröklött absztrakt metódusokat az override kulcsszó segítségével tudjuk definiálni 
(hiszen virtuálisak, még ha nem is látszik). 

Amennyiben egy osztálynak van legalább egy absztrakt metódusa, az osztályt is absztraktként kell jelölni. 

Annak ellenére, hogy egy absztrakt osztályt nem példányosíthatunk, még lehet konstruktora, mégpedig azért, 
hogy beállíthassuk vele az adattagokat: 


abstract eláss Animál 

{ 

public Animal(string name) 

{ 

this.Name = name; 

} 

public string Name { get; set; } 
abstract public void Eat(); 

} 
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eláss Dog : Animál 

{ 

public Dog(string name) : base(name) { } 

public override void Eat() 

{ 

Console.WriteLine( "Kutya eszik.. 

} 

} 


Vajon hogyan működik a következő példában a polimorfizmus elve? : 


Animal[] animalArray = new Animal[2]; 

animalArray[0] = new Dog("Füli"); 
animalArray[1] = new Crocodile("Aladár"); 


Ennek a kódnak hiba nélkül kell fordulnia, hiszen ténylegesen egyszer sem példányosítottuk az absztrakt 
ó'sosztályt. A fordító csak azt fogja megvizsgálni, hogy mi van a new operátor jobb oldalán, az alaposztály nem 
érdekli. Természetesen a következő esetben nem fordulna le: 


animalArray[0] = new Animal( "Animál") ; 
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Interfészek 


Az interfészek hasonlóak az absztrakt osztályokhoz, abban az értelemben, hogy meghatározzák egy osztály 
viselkedését, felületét. A nagy különbség a kettő' közt az, hogy míg előbbi eleve meghatároz egy 
osztályhierarchiát, egy interfész nem köthető közvetlenül egy osztályhoz, mindössze előír egy mintát, amely 
megvalósításra vár. Egy másik előnye az interfészek használatának, hogy míg egy osztálynak csak egy őse lehet, 
addig bármennyi interfészt megvalósíthat. Ezenfelül interfészt használhatunk struktúrák esetében is. A 
következő példában átírjuk az Animál ősosztályt interfészre: 


using System; 

namespace TestApp 

{ 

intenface IAnimal 

{ 

void Eat(); 

} 

eláss Dog : IAnimal 

{ 

public void Eat() 

{ 

Console.WriteLine("Kutya eszik... ")j 

} 

} 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Dog d = new Dog(); 
d.Eat(); 

Console .ReadKey(); 

} 

} 

} 


Az interfész nevét konvenció szerint nagy I betűvel kezdjük. Látható, hogy a metódusokhoz nem tartozik 
definíció, csak deklaráció. A megvalósító osztály dolga lesz majd implementálni a tagjait. Egy interfész a 
következőket tartalmazhatja: metódusok, tulajdonságok, indexelők és események (erről hamarosan). A 
tagoknak nincs külön megadott láthatóságuk, mindannyiuk elérhetősége publikus. Magának az interfésznek az 
elérhetősége alapesetben publikus, illetve jelölhetjük internal-ként, másféle láthatóságot nem adhatunk meg 
(illetve osztályon belül deklarált (beágyazott) interfész elérhetősége lehet privát). 

Egy interfészt implementáló osztálynak meg kell valósítania az interfész metódusait, egyetlen kivétellel: ha a 
szóban forgó osztály egy absztrakt osztály. Ekkor az interfész metódusait abszraktként jelölve elhalaszthatjuk a 
metódusdefiníciót az absztrakt osztály leszármazottainak implementálásáig: 


interface IAnimal 

{ 

void Eat(); 

} 

abstract eláss AbstractAnimal : IAnimal 

{ 

public abstract void Eat(); 

} 
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Fontos, hogy amennyiben egy osztályból is származtatunk, akkor a felsorolásnál az ó'sosztály nevét kell 
eló'revenni, utána jönnek az interfészek: 


eláss Base { } 
intenface IFace { } 

eláss Derived : IFace., Base { } // ez nem fordul le 


Egy interfészt származtathatunk más interfészekből: 


using System; 

namespace TestApp 

{ 

interface IAnimal 

{ 

void Eat(); 

} 

interface IDog : IAnimal 

{ 

void Vau(); 

} 

eláss Dog : IDog 

{ 

public void Eat() 

{ 

Console.WriteLine("Kutya eszik... "); 

} 

public void Vau() 

{ 

Console.WriteLine("Vau - Vau"); 

} 

} 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Dog d = new Dog(); 

d.Eat(); 

d.Vau(); 

Console .ReadKey(); 

} 

} 

} 


Ekkor természetesen az összes interfészt meg kell valósítanunk. 

Egy adott interfészt megvalósító objektumot implicit módon átkonvertálhatunk az interfész „típusára": 


Dog d = new Dog(); 
IAnimal ia = d; 
IDog id = d; 

ia.Eat(); 
id.Vau(); 


146 





Az is és as operátorokkal pedig azt is megtudhatjuk, hogy egy adott osztály megvalósít-e egy interfészt: 


Dog d = new Dog(); 

IAnimal ia = d as IAnimal; 

if (ia != null) 

{ 

Console.WriteLine("Az objektum megvalósítja az IAnimal -t"); 

} 

if (d is IDog) 

{ 

Console.WriteLine("Az objektum megvalósítja az IDog -ot"); 

} 


Explicit interfészimplementáció 

Ha több interfészt implementálunk, az névütközéshez is vezethet. Ennek kiküszöbölésére explicit módon 
megadhatjuk a megvalósítani kívánt funkciót: 


using System; 

namespace TestApp 

{ 

intenface IOne 

{ 

void Method(); 

} 

intenface ITwo 

{ 

void Method(); 

} 

eláss Test : IOne., ITwo 

{ 

public void Method() 

{ 

Console.WniteLine("Method!"); 

} 

} 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

Test t = new Test(); 
t.Method(); 

Console .ReadKey(); 

} 

} 

} 


Ez a forráskód lefordul, és a metódust is meg tudjuk hívni. A probléma ott van, hogy két metódust kellene 
implementálnunk, de csak egy van - viszont a program működik. Persze nem ez az elvárt viselkedés, ezért ilyen 
esetekben explicit módon meg kell mondanunk, hogy melyik metódus/tulajdonság/stb. melyik interfészhez 
tartozik. írjuk át a fenti kódot: 
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eláss Test : IOne, ITwo 

{ 

void IOne .Method() 

{ 

Console.WriteLine( "IOne Method! "); 

} 

void ITwo. Method() 

{ 

Console.WriteLine("ITwo Method! ")j 

} 

} 


Vegyük észre, hogy nem használtunk láthatósági módosítót, ilyenkor az interfész láthatósága érvényes ezekre a 
tagokra. 

Újabb problémánk van, méghozzá az, hogy hogyan fogjuk meghívni a metódusokat. Most fogjuk kihasználni, 
hogy egy osztály konvertálható a megvalósított interfészek típusára: 


Test t = new Test(); 

((IOne)t) .Method(); // ez működik 
ITwo it = t; 

it.MethodQ; // ez is működik 


Virtuális tagok 

Egy interfész tagjai alapértelmezés szerint lezártak, de a megvalósításnál jelölhetjük ó'ket virtuálisnak. Ezután az 
osztály leszármazottjai tetszés szerint módosíthatják a definíciót, a már ismert override kulcsszóval: 


eláss Dog : IDog, IAnimal 

{ 

public void Eat() 

{ 

Console.WniteLine( "Kutya eszik.. ."); 

} 

public vintual void Vau() 

{ 

Console.WniteLine( "Vau - Vau"); 

} 

} 

eláss BigDog : Dog 

{ 

public override void Vau() 

{ 

Console.WriteLine( "VAU-VAU") ; 

} 

} 


Egy leszármazott újraimplementálhatja az adott interfészt, amennyiben nemcsak az ó'snél, de az utódnál is 
jelöljük a megvalósítást: 


eláss BigDog : Dog, IAnimal 

{ 

public new void Eat() 

{ 


148 






Console.WniteLine( "Kutya nagyon eszik.. 

} 

• "); 

public ovenride void Vau() 

{ 

Console. WriteLine( "VAU-VAU") ; 

} 

} 



Ez esetben használnunk kell a new kulcsszót annak jelölésére, hogy eltakarjuk az ó's megvalósítását. 
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Operátor kiterjesztés 


Nyilván szeretnénk, hogy az általunk készített típusok hasonló funkcionalitással rendelkezzenek, mint a 
beépített típusok (int, string stb.). 

Vegyük pl. azt a példát, amikor egy mátrix típust valósítunk meg! Jó lenne, ha az összeadás, kivonás, szorzás stb. 
műveleteket úgy tudnánk végrehajtani, mint egy egész szám esetében, nem pedig metódushívásokkal. 
Szerencsére a C# ezt is lehetó'vé teszi számunkra, ugyanis engedi az operátorok kiterjesztését (operator 
overloading), vagyis egy adott operátort tetszés szerinti funkcióval ruházhatunk fel az osztályunkra 
vonatkoztatva. 


Mátrix ml = new Matrix(20, 20); 
Mátrix m2 = new Matrix(20j 20); 

//ez is jó 
ml.Add(m2); 

//de ez még jobb lenne 
ml += m2; 


A kiterjeszthető operátorok listája: 


+(unáris) 

-(unáris) 


- 

++ 

— 

+ 

- 

* 

/ 

% 

& 

1 

A 

« 

» 

= = 

i= 

> 

< 

>= 

<= 





A C# nyelvben az operátorok valójában statikus metódusok, paramétereik az operandusok, visszatérési értékük 
pedig az eredmény. Egy egyszerű példa: 


eláss Mylnt 

{ 

public Mylnt(int value) 

{ 

this. Value = value; 

} 

public int Value { get; priváté set; } 

static public Mylnt operator +(MyInt lhs., Mylnt rhs) 

{ 

return new Mylnt(lhs .Value + rhs.Value); 

} 

} 


A '+' operátor működését fogalmaztuk át. A paraméterek (operandusok) nevei konvenció szerint Ihs (left-hand- 
side) és rhs (right-hand-side), utalva a jobb és bal oldali operandusra. 

Tehát most már nyugodtan írhatom a következőt: 


Mylnt x = new Mylnt(10); 

Mylnt y = new Mylnt(20); 

Mylnt result = x + y; 

Console.WriteLine(result.Value); // 30 
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Mivel definiáltunk az osztályunkon egy saját operátort, így a fordító tudni fogja, hogy azt használja, és átalakítja 
a műveletet az alább látható módon. Ezt azonban csakis a fordító teheti meg, nekünk a „rendes" formát kell 
használnunk. 


Mylnt result = Mylnt. operator+(x, y); 


Egyenlőség operátorok 

A .NET megfogalmaz néhány szabályt az operátor-kiterjesztéssel kapcsolatban. Ezek egyike az, hogy ha 
túlterheljük az egyenló'ség operátort (==), akkor definiálnunk kell a nem-egyenló' (!=) operátort is: 


eláss Mylnt 

{ 

public Mylnt(int value) 

{ 

this. Value = value; 

} 

public int Value { get; priváté set; } 

static public Mylnt operator +(MyInt lhs, Mylnt rhs) 

{ 

return new Mylnt(lhs .Value + rhs.Value); 

} 

static public bool operator ==(MyInt lhs, Mylnt rhs) 

{ 

return lhs.Value == rhs.Value; 

} 

static public bool operator !=(MyInt lhs, Mylnt rhs) 

{ 

return !(lhs == rhs); 

} 

} 


A nem-egyenló' operátor esetében a saját egyenlőség operátort használtuk fel. A megvalósítás elve nem 
feltétlenül világos, elsőként megvizsgáljuk, hogy a két elem egyenlő-e, de mi a nem-egyenlőségre vagyunk 
kíváncsiak, ezért tagadjuk az eredményt, ami pontosan ezt a választ adja meg. 

Ezekhez az operátorokhoz tartozik a System.Object típustól örökölt virtuális Equals metódus is, ami a CLS 
kompatibilitást hivatott megőrizni, erről később még lesz szó. A fenti esetben ezt a metódust is illik 
megvalósítani. Az Equals azonban egy kicsit különbözik, ő egyetlen object típusú paramétert vár, ezért meg kell 
majd győződnünk arról, hogy valóban a saját objektumunkkal van-e dolgunk: 


public override bool Equals(object rhs) 

{ 

if (!(rhs is Mylnt) ) 

{ 

return false; 

} 

return this == (Mylnt)rhs; 

} 


Mivel ez egy példány tag, ezért a this-t használjuk az objektum jelölésére, amin meghívtuk a metódust. 
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Ha az Equals -t megvalósítottuk, akkor ezt kell tennünk a szintén az object -tó'l öröklött GetHashCode 
metódussal is, így az osztály használható lesz gyűjteményekkel és a HashTable típussal is. A legegyszerűbb 
implementáció visszaad egy számot az adattag(ok)ból számolva (pl.: hatványozás, biteltolás stb...): 

public overnide int GetHashCode() 

{ 

neturn this.Value << 2; 

} 


A ++/-- OPERÁTOROK 

Ez a két operátor elég nagy fejfájást tud okozni, nézzük meg a következő' kódot: 


using System; 

namespace TestApp 

{ 

eláss Mylnt 

{ 

public Mylnt(int value) 

{ 

this.Value = value; 

} 

public int Value { get; priváté set; } 

static public Mylnt operator ++(MyInt rhs) 

{ 

++rhs.Value; 
return rhs; 

} 

} 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Mylnt x = new Mylnt (10); 
Console.WriteLine(x.Value); // 10 
++x; 

Console.WriteLine(x.Value); // 11 
Mylnt y = x++; 

Console.WriteLine(x.Value); // 12 
Console.WriteLine(y.Value); // 12 (!) 

Console .ReadKey(); 

} 

} 

} 


Nézzük az utolsó sort! Mivel y a postfixes formában kapott értéket, ezért 11-et kellene tartalmaznia, ehelyett 
x++ esetében pontosan ugyanaz történik, mint ha ++x-et írtunk volna. 

A probléma, hogy kifejezetten postfixes operátort nem tudunk definiálni, az általunk készített kód minden 
esetben a prefix operátort jelenti. Viszont meghívhatjuk az általunk definiált operátorokat postfixes alakban, 
ekkor az adott objektumot eltárolja a rendszer, meghívja az értéket növelő kódrészletet, és visszadja az első 
lépésben félrerakott értéket. Ugye ez értéktípusok esetében tökéletesen működik, de referenciatípusoknál az 
első lépésben nem az értéket, hanem a referenciát tároljuk, vagyis a későbbi változás itt is érvényben lesz. 
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Ugyanakkor létezik módszer arra, hogy mégis megoldjuk a fenti problémát: az operátornak egy teljesen új 
objektumot kell visszaadnia, ekkor erre már nem mutat korábbi referencia, vagyis biztonságosan használható, 
viszont az új művelet (az objektum létrehozása) miatt a teljesítményre negatív hatással lehet (ez persze néha 
elfogadható). 


Relációs operátorok 

Hasonlóan a logikai operátorokhoz, a relációs operátorokat is csak párban lehet elkészíteni, vagyis (<, >) és (<=, 
>=): 


static public bool operator < (Mylnt lhs, Mylnt rhs) 

{ 

return lhs.Value < rhs.Value; 

} 

static public bool operator >(MyInt lhs, Mylnt rhs) 

{ 

return lhs.Value > rhs.Value; 

} 


Ebben az esetben az IComparable és IComparable<T> interfészek megvalósítása is szükséges lehet a különböző 
gyűjteményekkel való együttműködés érdekében. Ezekkel hamarosan megismerkedünk. 


Konverziós operátorok 

A C# a szűkebbről tágabbra konverziókat implicit módon (azaz különösebb jelölés nélkül), míg a tágabbról 
szűkebbre konvertálást explicite (ezt jelölnünk kell) végzi. Természetesen szeretnénk, hogy a saját típusunk is 
képes legyen ilyesmire, és bizony erre is létezik operátor. Ezeknél az operátoroknál az implicit illetve explicit 
kulcsszavakkal fogjuk jelölni a konverzió típusát: 


static public implicit operator Mylnt(int rhs) 

{ 

return new Mylnt(rhs); 

} 


static public explicit operator Mylnt(string rhs) 

{ 

return new MyInt(int.Parse(rhs)); 

} 


Ezeket most így használhatjuk: 


Mylnt x = 10; // implicit konverzió 
Mylnt y = (Mylnt)"20"; //explicit konverzió 


Fontos, hogy a konverziós operátorok mindig statikusak. 
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Kivételkezelés 


Vannak esetek, amikor az alkalmazásunk, gond nélkül lefordul, mégsem úgy működni, ahogy elképzeltük. Az 
ilyen „abnormális" működés kezelésére találták ki a kivételkezelést. Amikor az alkalmazásunk „rossz" állapotba 
kerül, akkor egy ún. kivételt fog dobni, ilyennel már találkoztunk a tömböknél, amikor túlindexeltünk: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

int[] array = new int[2]; 
array[2] = 10; 

} 

} 

} 


Itt az utolsó érvényes index az 1 lenne, így kivételt kapunk, mégpedig egy System.IndexOutOfRangeExceptio-t. 
Ezután a program leáll. Természetesen mi azt szeretnénk, hogy valahogy kijavíthassuk ezt a hibát, ezért el 
fogjuk kapni a kivételt. Ehhez a művelethez három dologra van szükségünk: kijelölni azt a programrészt, ami 
dobhat kivételt, elkapni azt, és végül kezelni a hibát: 


using System; 

namespace TestApp 

{ 


eláss Program 

{ 


static void Main(string[] args) 

{ 

int[] array = new int[2]; 

try 

{ 

array[2] = 10; 

} 

catch (System. IndexOutOfRangeException 

{ 

Console .WriteLine(e.Message); 


} 


e) 


} 


} 


Console. ReadKey(); 

} 


A try blokk jelöli ki a lehetséges hibaforrást, a catch pedig elkapja a megfelelő' kivételt (arra figyeljünk, hogy 
ezek is blokkok, azaz a blokkon belül deklarált változók a blokkon kívül nem láthatóak). A fenti programra a 
következő lesz a kimenet: 


Index was outside the bounds of the array 


Látható, hogy a kivétel egy objektum formájában létezik. Minden kivétel őse a System.Exception osztály, így ha 
nem speciálisan egy kivételt akarunk elkapni, akkor írhattuk volna ezt is: 
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try 

{ 


array[2] = 10; 

} 

catch (System. Exception e) 

{ 

Console.WriteLine(e.Message); 

} 


Ekkor minden kivételt el fog kapni a catch blokk. A System.Exception tulajdonságai közül kettőt kell 
megemlítenünk: 

• Message: ez egy olvashatóbb formája a kivétel okának. 

• InnerException: ez alapértelmezetten null értékkel rendelkezik, akkor kap értéket, ha több kivétel is 
történik. Értelemszerűen ekkor a legújabb kivételt kaphatjuk el, és az InnerException-ön keresztül 
követhetjük vissza az eredeti kivételig. 

Nézzük meg, hogyan működnek a kivételek! Kivétel két módon keletkezhet: vagy a throw utasítással 
szándékosan mi magunk idézzük elő, vagy az alkalmazás hibás működése miatt. 

Abban a pillanatban, amikor a kivétel megszületik, a rendszer azonnal elkezdi keresni a legközelebbi megfelelő 
catch blokkot, elsőként abban a metódusban, amelyben a kivétel keletkezett, majd ha ott nem volt sikeres, 
akkor abban, amely ezt a metódust hívta (és így tovább, amíg nem talál olyat, amely kezelné). 

A keresés közben két dolog is történhet. Ha egy statikus tag vagy konstruktőr inicializálása történik, az ekkor 
szintén kivétellel jár, méghozzá egy System.TypelnitializationException-nel, amely kivételobjektum 
InnerException tulajdonságába kerül az eredeti kivétel. A másik lehetőség, hogy nem talál megfelelő catch 
blokkot, ekkor a program futása - hibaüzenet társaságában - leáll. 

Ha mégis talált használható catch blokkot, akkor a kivétel helyéről a vezérlés a talált catch -re kerül. Ha több 
egymásba ágyazott kivételről van szó, akkor a megelőző catch blokkhoz tartozó finally blokk fut le, majd ezután 
következik a catch blokk. 

Kivételt a throw utasítással dobhatunk: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

try 

{ 

throw new System. Exception("Kivétel. Hurrá!"); 

} 

catch (Exception e) 

{ 

Console.WriteLine(e.Message); 

} 

Console .ReadKey(); 

} 

} 

} 


A catch-nek nem kötelező megadni a kivétel típusát, ekkor minden kivételt elkap: 
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try 

{ 

throw new System. Exception( ); 

} 

catch 

{ 

Console.WriteLine("Kivétel. Hurrá! "); 

} 


Ilyenkor viszont nem használhatjuk a kivételobjektumot. 


Kivétel hierarchia 

Amikor kivétel dobódik, akkor a vezérlést az első alkalmas catch blokk veszi át. Mivel az összes kivétel a 
System.Exception osztályból származik, így ha ezt adjuk meg a catch-nél, akkor az összes lehetséges kivételt el 
fogjuk kapni vele. Egyszerre több catch is állhat egymás után, de ha van olyan, amelyik az ős kivételt kapja el, 
akkor a program csak akkor fog lefordulni, ha az az utolsó helyen áll, hiszen a többinek esélye sem lenne. 


try 

{ 

int[] array = new int[2]; 
array[3] = 10; 

} 

catch (System. IndexOutOfRangeException) 

{ 

Console .WriteLine( "OutOfRangé" ); 

} 

catch (System. Exception) 

{ 

Console. WriteLine( "Exception") ; 

} 


Látható, hogy a catch-nek elég csak a kivétel típusát megadni, persze ekkor nem használhatjuk a 
kivételobjektumot. 


Kivétel készítése 


Mi magunk is készíthetünk kivételt, a System.Exception-ből származtatva: 


using System; 

namespace TestApp 

{ 

eláss MyException : System. Exception 

{ 

public MyException() { } 

public MyException(string message) 

: base(message) 

{ 

} 

public MyException(string message, Exception inner) 
: base(message, inner) 

{ 

} 
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} 

eláss Program 

{ 

static void Main(string[] args) 

{ 

try 

{ 

throw new MyException("Kivétel. Hurrá!"); 

} 

catch (MyException e) 

{ 

Console.WriteLine(e.Message); 

} 

Console .ReadKey(); 

} 

} 

} 


Kivételek továbbadása 


Egy kivételt az elkapása után ismét eldobhatunk. Ez hasznos olyan esetekben, amikor feljegyzést akarunk 
készíteni, illetve ha egy specifikusabb kivételkezelőnek akarjuk átadni a kivételt: 


try 

{ 

} 

catch (System. ArgumentException e) 

{ 

throw; //továbbadjuk 

throw (new System. ArgumentNullException()); //vagy egy újat dobunk 

} 


Ilyenkor beállíthatjuk az Exception InnerException tulajdonságát is: 


try 

{ 

throw new Exception(); 

} 

catch (System. ArgumentException e) 

{ 

throw (new System.ArgumentNullException("Tovább"j 


} 


e)); 


Itt az Exception osztály harmadik konstruktőrét használtuk, az új kivétel már tartalmazni fogja a régit is. 


Finally blokk 

A kivételkezelés egy problémája, hogy a kivétel keletkezése után az éppen végrehajtott programrész futása 
megszakad, így előfordulhat, hogy nem szabadulnak fel időben az erőforrások (megnyitott fájl, hálózati 
kapcsolat stb.), illetve objektumok olyan formában maradnak meg a memóriában, amely hibát okozhat. 
Megoldást a finally— blokk használata jelent, amely függetlenül attól, hogy történt-e kivétel, mindig lefut: 
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using System; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

int x = 10; 

try 

{ 

Console.WriteLine("x értéke a kivétel előtt: {0}"., x); 
throw new Exception(); 

} 

catch (Exception) 

{ 

Console.WriteLine("Kivétel. Hurrá! "); 

} 

finally 

{ 

Console.WriteLine( "Finally blokk"); 
x = 11; 

} 

Console.WriteLine("x értéke a kivétel után {0}"., x); 


Console .ReadKey(); 

} 

} 

} 


„Valódi" erőforrások kezelésekor kényelmesebb a using-blokk használata (Id. IDisposabie fejezet), mivel az 
automatikusan lezárja azokat. Lényegében a using-blokkal használt erőforrások fordítás után a megfelelő try- 
catch-finally blokkokká alakulnak. 
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Gyakorló feladatok IV. 


IEnumerator és IEnumerable 

Készítsünk osztályt, amely megvalósítja az IEnumerator és IEnumerable interfészeket! 

Megoldás 

Korábban már találkoztunk a foreach ciklussal, és már tudjuk, hogy csak olyan osztályokon képes végigiterálni, 
amelyek megvalósítják az IEnumerator és IEnumerable interfészeket. Mindkettő' a System.Collections 
névtérben található. 

Elsőként nézzük az IEnumerable interfészt: 


public interface IEnumerable 

{ 

IEnumerator GetEnumerator(); 

} 


Ez a foreach-nek fogja szolgáltatni a megfelelő felületet, ugyanis a ciklus meghívja a metódusát, és annak vissza 
kell adnia az osztályt lEnumerator-ként (Id. implicit konverzió). Ezért kell megvalósítani egyúttal az IEnumerator 
interfészt is, ami így néz ki: 


public interface IEnumerator 

{ 

bool MoveNext(); 
void ResetQ; 

object Current { get; } 

} 


A MoveNext a következő elemre mozgatja a mutatót, ha tudja, ellenkező esetben (vagyis ha a lista végére ért) 
false értékkel tér vissza. A Rését alapértelmezésre állítja a mutatót, azaz -1 -re. Végül a Current (read-only) 
tulajdonság az aktuális pozícióban lévő elemet adja vissza. Ennek object típussal kell visszatérnie, hiszen 
minden típusra működnie kell (létezik generikus változata is, de erről később). 

Használjuk az Animál osztályunk egy kissé módosított változatát: 


public eláss Animál 

{ 

public Animal(string name) 

{ 

this.Name = name; 

} 

public string Name { get; priváté set; } 

} 


Most készítsünk egy osztályt, amelyen megvalósítjuk a két interfészt, és ami tartalmaz egy Animál 
objektumokból álló listát: 


public eláss AnimalContainer : IEnumerable, IEnumerator 

{ 

priváté ArrayList Container = new ArrayList(); 
priváté int currPosition = -1; 
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public AnimalContainer() 

{ 

Container.Add (new Animál ( "Füli") ); 
Container.Add (new Animal( "Bundás ") ); 
Container.Add (new Animál ( "Parizer") ); 

} 

} 


Ez persze még nem az egész osztály, felvettünk egy ArrayListet, amiben eltároljuk az objektumokat, illetve 
deklaráltunk egy egész számot, ami az aktuális pozíciót tárolja el, és kezdó'értékéül -1-et adtunk (Id. Rését). 
Készítsük el az lEnumerator által igényelt metódusokat: 


public bool MoveNext() 

{ 

return (++currPosition < Container.Count); 

} 

public object: Current 

{ 

get { return Container[currPosition]; } 

} 

public void Reset() 

{ 

currPosition = -1; 

} 


Végül az lEnumerable interfészt valósítjuk meg: 


public lEnumerator GetEnumerator() 

{ 

return (IEnumerator)this; 

} 


Ezután használhatjuk is az osztályt: 


AnimalContainer ac = new AnimalContainer(); 

foreach (Animál animal in ac) 

{ 

Console. WriteLine(animal.Name); 

} 


Amennyiben a foreach-en kívül akarjuk használni az osztályt, pl. ha készítettünk indexeló't is, akkor 
gondoskodnunk kell a megfelelő' konverzióról is (a foreach kivételt képez, mivel ő ezt megteszi helyettünk). 

ICOMPARABLE ÉS ICOMPARER 

Valósítsuk meg az IComparable illetve IComparer interfészt! 

Megoldás 

A második gyakorlati példánkban az IComparable interfészt fogjuk megvalósítani, amelyre gyakran van 
szükségünk. Ez az interfész általában olyan adatszerkezeteknél követelmény, amelyek az elemeiken 
megvalósítanak valamilyen rendezést. A generikus List típusnak is van rendező metódusa (Sort), amely ezzel a 
metódussal dolgozik. Az IComparable egyetlen metódussal, a CompareTo-val rendelkezik, amely egy object 
típust kap paraméteréül: 
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eláss ComparableClass : IComparable 

{ 

public ComparableClass(int value) 

{ 

this. Value = value; 

} 

public int Value { get; priváté set; } 

public int CompareTo(object o) 

{ 

if (o is ComparableClass) 

{ 

ComparableClass c = (ComparableClass)o; 

return Value.CompareTo(c.Value); 

} 

else throw (new Exception( "Nem megfelelő objektum...")); 

} 

} 


Az osztályban a beépített típusok CompareTo metódusát használtuk, hiszen ők mind megvalósítják ezt az 
interfészt. Ez a metódus -1-et ad vissza, ha a hívó fél kisebb, 0-át, ha egyenlő és 1-et, ha nagyobb. A 
használata: 


List<ComparableClass> üst = new List<ComparableClass>( ); 
Random r = new Random(); 

fór (int i = 0; i < 10; ++i) 

{ 

üst.Add (new ComparableClass (r.Next(1000))); 

} 

foreach (ComparableClass c in üst) 

{ 

Console.Write("{0} ", c.Value); 

} 

Console.WriteLine("\nA rendezett lista:"); 
list.Sort(); 

foreach (ComparableClass c in üst) 

{ 

Console.Write("{0} ", c.Value); 

} 


A List<T> tipus használatához szükség van a System.Collections.Generic névtérre, bővebben a Generikusok 
című fejezetben olvashatunk róla. 


Hasonló feladatot lát el, de jóval rugalmasabb az IComparer interfész. Az IComparer osztályok nem részei az 
„eredeti" osztályoknak, így olyan osztályok esetén is használhatunk ilyet, amelyek implementációjához nem 
férünk hozzá. 

Például a List<T> rendezésénél megadhatunk egy összehasonlító osztályt, amely megvalósítja az IComparer 
interfészt, így tetszőleges rendezést valósíthatunk meg anélkül, hogy ki kellene egészíteni magát a List<T> -t. 
Most is csak egy metódust kell elkészítenünk, ez a Compare, amely két object típust vár paramétereként 
(illetve felhasználtuk az előzőleg elkészített ComparableClass osztályt): 


eláss ComparableClassComparer : IComparer 

{ 
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public int Compare(object x, object y) 

{ 

if(x is ComparableClass && y is ComparableClass) 

{ 

ComparableClass _x = (ComparableClass)x; 
ComparableClass _y = (ComparableClass)y; 

return _x.CompareTo(_y); 

} 

else throw(new Exception( "Nem megfelelő paraméter... "); 

} 

} 


A metódus elkészítésénél az egyszerűség miatt feltételeztük, hogy az összehasonlított osztály megvalósítja az 
IComparable interfészt (a beépített típusok ilyenek), természetesen mi magunk is megírhatjuk az eredményt 
előállító programrészt. Ezután a következőképpen rendezhetjük a listát: 


üst.Sort (new ComparableClassComparer( )); 


Az IComparer előnye, hogy nem kötődik szorosan az osztályhoz (akár anélkül is megírhatjuk, hogy ismernénk a 
belső szerkezetét), így többféle megvalósítás is lehetséges. 


Mátrix típus 

Készítsük el a mátrix típust, és valósítsuk meg rajta az összeadás műveletet! Az egyszerűség kedvéért tegyük fel, 
hogy a mátrix csak egész számokat tárol! 

Megoldás 


eláss Mátrix 

{ 

int[j] mátrix; 

public Matrix(int n, int m) 

{ 

mátrix = new int[n, m]; 

} 

public int N 

{ 

get { return mátrix.GetLength(0); } 

} 

public int M 

{ 

get { return mátrix.GetLength(l); } 

} 

public int this[int idxn, int idxm] 

{ 

get { return matrixfidxn, idxm]; } 
set { matrixfidxnj idxm] = value; } 

} 

static public Mátrix operator +(Matrix lhs, Mátrix rhs) 

{ 

if (lhs.N != rhs.N || lhs.M != rhs.M) return null; 
Mátrix result = new Matrix(lhs.N, lhs.M); 
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fór (int i = 0 ; i < 

lhs.N; ++i) 


{ 



fór (int j = 0j 

j < lhs.M; ++j) 


{ 



result[ij j 

= lhs[ij j] + rhs[ij j]j 


} 



} 



return result; 



} 


} 



Mátrixokat úgy adunk össze, hogy az azonos indexeken lévő értékeket összeadjuk: 

123 

145 1+1 2+4 3+5 


456 

+ 532 = (stb.) 


789 

211 



Az összeadás műveletet csakis azonos nagyságú dimenziók mellett lehet elvégezni (3x3-as mátrixhoz nem lehet 
hozzáadni egy 4x4 -eset). Ezt ellenőriztük is az operátor megvalósításánál. 

Most csak az összeadás műveletet valósítottuk meg, a többi a kedves olvasóra vár. Plusz feladatként 
indexellenőrzést is lehet végezni az indexelőnél. 
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Delegate 


A delegate olyan típus, amely egy vagy több metódusra hivatkozik. Minden delegate különálló objektum, amely 
egy listát tárol a meghívandó metódusokról (értelemszerűen ez egyúttal erős referencia is lesz a metódust 
szolgáltató osztályra). Nemcsak példány-, hanem statikus metódusokra is mutathat. Egy delegate 
deklarációjánál megadjuk, hogy milyen szignatúrával rendelkező metódusok megfelelőek: 


delegate int TestDelegate(int x)j 


Delegate nem deklarálható blokkon belül, csakis osztályon belül tagként, illetve osztályokon kívül (hasonlóan az 
enum típusokhoz). Ez a delegate olyan metódusra mutathat, amelynek visszatérési értéke int típusú és 
egyetlen int paramétere van, pl.: 


static public int Pow(int x) 

{ 

retunn (x * x); 

} 


A használata: 


TestDelegate dlgt = Pow; 
int result = dlgt(10); 


A delegate-ekhez egynél több metódust is hozzáadhatunk a += és + operátorokkal, valamint elvehetjük őket a - 
= és - operátorokkal. A delegate hívásakor a listáján lévő összes metódust meghívja a megadott paraméterre. 


eláss Test 

{ 

public delegate void TestDelegate(string msg); 
priváté TestDelegate handler; 

public Test() 

{ 

handler += Test.StaticMethod; 
handler += this.InstanceMethod; 

} 

static public void StaticMethod(string msg) 

{ 

Console.WriteLine(msg); 

} 

public void InstanceMethod(string msg) 

{ 

Console.WriteLine(msg); 

} 

public void CallDelegate(string msg) 

{ 

handler(msg); 

} 

} 


A delegate-ek legnagyobb haszna, hogy nem kell előre megadott metódusokat használnunk, ehelyett később 
tetszés szerint adhatjuk meg az elvégzendő műveletet: 
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eláss Array 

{ 

public delegate void Transformer(ref int item); 

priváté int[] array; 

public Array(int length) 

{ 

Length = length; 
array = new int[Length]; 

} 

public int Length { get; set; } 

public int this[int idx] 

{ 

get { return array[idx]; } 
set { array[idx] = value; } 

} 

public void Transform(Transformer t) 

{ 

fór (int i = 0; i < array.Length; ++i) 

{ 

t(ref array[i]); 

} 

} 

} 


A Transform metódus egy delegate-et kap paraméteréül, amely elvégzi a változtatásokat a tömbön. PL: 


eláss Program 

{ 

static public void TransformerMethod(ref int item) 

{ 

item *= item; 

} 

static void Main(string[] args) 

{ 

Array array = new Array(10); 

fór (int i = 0; i < array.Length; ++i) 

{ 

array[i] = i; 

} 

array.T ransform( Program. TransformerMethod); 

fór (int i = 0; i < array.Length; ++i) 

{ 

Console.WriteLine(array[i]); 

} 

Console. ReadKeyQ; 

} 

} 


Két delegate szerkezetileg nem egyenlő', még akkor sem ha a szignatúrájuk megegyezik: 
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using System; 

namespace TestApp 

{ 

eláss Program 

{ 

public delegate void Dlgtl(); 
public delegate void Dlgt2(); 

static public void Method() { } 

static void Main(string[ ] args) 

{ 

Dlgtl dl = Program.Method; 
Dlgt2 d2 = dl; // ez hibás 

} 

} 

} 


Ugyanakkor ugyanazon delegate „típus" példányai között használhatjuk az == és != operátorokat. Két delegate 
egyenlő', ha mindkettő értéke null, illetve ha a híváslistájukon ugyanazon objektumok ugyanazon metódusai 
szerepelnek (vagy ugyanazok a statikus metódusok): 


using System; 

namespace TestApp 

{ 

eláss Test 

{ 

public void Method() { } 

} 

eláss Program 

{ 

public delegate void TestDelegate( ); 

static public void MethodlQ { } 
static public void Method2() { } 

static void Main(string[] args) 

{ 

TestDelegate ti = null; 

TestDelegate t2 = null; 

Console.WriteLine(tl == t2); // True 

ti = Program.Methodl; 
t2 = Program.Methodl; 

Console.WriteLine(tl == t2); // True 

ti += Program.Method2; 

Console.WriteLine(tl == t2); // False 

ti -= Program.Method2; 

Test x = new Test(); 

Test y = new Test(); 
ti += x.Method; 
t2 += y.Method; 
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} 


} 


Console. WriteLine(tl == t2); // False 
Console .ReadKey(); 


Paraméter és visszatérési érték 

Egy delegate-nek átadott metódus paraméterei lehetnek olyan típusok, amelyek az eredeti paraméternél 
általánosabbak: 


using System; 

namespace TestApp 

{ 

eláss Animál { } 

eláss Dog : Animál { } 

eláss Cat : Animál { } 

eláss Program 

{ 

public delegate void DogDelegate(Dog d); 

static public void AnimalMethod(Animal a) { } 

static void Main(string[ ] args) 

{ 

DogDelegate d = AnimalMethod; 

Console .ReadKey(); 

} 

} 

} 


Ez az ún. kontravariáns (contravariant) viselkedés. Ennek a fordítottja igaz a visszatérési értékre, azaz az átadott 
metódus visszatérési értéke lehet specifikusabb az eredetinél: 


using System; 

namespace TestApp 

{ 

eláss Animál { } 

eláss Dog : Animál { } 

eláss Cat : Animál { } 

eláss Program 

{ 

public delegate Animál GetAnimal(); 

static public Animál AnimalMethod() { return new Animal(); } 
static public Dog DogMethod() { return new Dog(); } 
static public Cat CatMethod() { return new Cat(); } 
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static void Main(string[ ] args) 

{ 

GetAnimal ga = AnimalMethod; 

Animál a = ga(); 

ga = DogMethod; 

Dog d = (Dog)gaQ; 

ga = CatMethod; 

Cat c = (Cat)ga(); 

Console. WriteLineC'10}, {1}, {2}"., 

a.GetType(), d.GetType(), c.GetType()); 

Console .ReadKey(); 

} 

} 

} 


Ezt pedig kovariáns (covariant) viselkedésnek nevezzük. 


Névtelen metódusok 

Egy delegate számára nem kötelező létező metódust megadnunk, lehetőségünk van helyben kifejteni egyet. 
Természetesen ez a névtelen metódus a program többi részéből közvetlenül nem hívható, csak a delegate-en 
keresztül. 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

public delegate void Test(int x); 

static void Main(string[] args) 

{ 

Test t = delegate(int x) 

{ 

Console.WriteLine(x); 

}J 

t(i0); 

Console .ReadKey(); 

} 

} 

} 


Egy névtelen metódus eléri az őt tároló blokk lokális változóit, és módosíthatja is őket: 


using System; 

namespace TestApp 

{ 

eláss Program 

{ 

public delegate void Test(); 
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static void Main(stning[ ] args) 

{ 

int x = 10; 

Test t = delegate() 

{ 

x = 11; 

Console.WriteLine(x); 

}J 

t(); 

Console .ReadKey(); 

} 

} 

} 


Ilyenkor figyelni kell arra, hogy a külső változóra a delegate is erős referenciával mutat, vagyis a változó akkor 
válik eltakaríthatóvá, ha a delegate maga is érvényét veszti. 

Névtelen metódus nem használhat semmilyen ugró utasítást (pl.: goto, break stb.). 
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Események 


Egy osztály eseményeket (event) használhat, hogy a saját állapota megváltozásakor értesítsen más osztályokat. 
Ehhez a „megfigyelő" osztályoknak fel kell iratkozni a „megfigyelt" osztály eseményére azáltal, hogy az előbbiek 
rendelkeznek egy, az eseménynek megfelelő szignatúrájú metódussal, ún. eseménykezelővel. Az esemény 
megtörténtekor ezek a metódusok fognak lefutni. Eddig ez nagyon úgy hangzik, mintha a delegate-ekről 
beszéltünk volna, és valóban egy esemény tulajdonképpen egy speciális delegate, mindössze három dologban 
különböznek: 

• Esemény lehet része interfésznek, míg delegate nem. 

• Egy eseményt csakis az az osztály „hívhat" meg, amely deklarálta. 

• Egy esemény rendelkezik add és remove „metódusokkal", amelyek felülbírálhatóak. 

Egy esemény deklarációjában meg kell adnunk azt a delegate-et, amely az eseményhez szükséges szignatúrát 
definiálja. Nézzünk egy egyszerű példát: 


eláss Test 

{ 

public delegate void EventHandlerDelegate(string message); 
public event EventHandlerDelegate TestStatusChange; 

priváté int data = 10; 
public int Data 
{ 

get { return data; } 
set 
{ 

data = value; 

this .OnStatusChangeQ; 

} 

} 

priváté void OnStatusChangeQ 

{ 

if (TestStatusChange != null) 

{ 

TestStatusChange( "Az osztály állapota megváltozott!"); 

} 

} 


Nem feltétlenül kell delegate-et deklarálnunk, mivel rendelkezésünkre áll a beépített általános EventHandler 
delegate, amely két paraméterrel (erről hamarosan) rendelkezik, és void visszatérési típussal bír. 

Az esemény akkor fog beindulni, amikor a data mező értéke megváltozik. Ekkor meghívjuk az OnStatusChanged 
metódust, amely elsőként megvizsgálja, hogy az eseményre feliratkoztak-e vagy sem - utóbbi esetben a hívás 
kivételt váltana ki. Ezt az osztály így használhatjuk: 


eláss Program 

{ 

static public void Handler(string message) 

{ 

Console.WriteLine( message); 

} 

static void Main(string[] args) 

{ 

Test t = new TestQ; 


170 




t.TestStatusChange += Program.Handler; 
t .Data = 11; 

Console. ReadKey(); 

} 

} 


A fenti kódban a TestStatusChange gyakorlatilag delegate-ként működik, vagyis egy saját listát tart fenn a 
meghívandó metódusokról (eseménykezeló'kről). 

Az eseményekhez rendelt eseménykezeló'knek konvenció szerint (ettó'l eltérhetünk, de a Framework eseményei 
mind ilyenek) két paramétere van, az első' az az objektum, amely kiváltotta az eseményt, a második pedig az 
eseményhez kapcsolódó információk. A második paraméter ekkor olyan típus lehet, amely az EventArgs 
osztályból származik. Módosítsuk ennek megfeleló'en a fenti programot! Elsőként készítünk egy EventArgs 
osztályból származó új osztályt, amely képes tárolni az eseményhez kapcsolódó üzenetet (az EventArgs 
alapértelmezetten nem rendelkezik ilyesmivel, csak egy alaposztály a specializált eseményekhez): 


eláss TestEventArgs : EventArgs 

{ 

public TestEventArgs(string message) 
: base() 

{ 

this. Message = message; 

} 

public string Message { get; set; } 


Ezután már csak módosítani kell a delegate-et és az esemény kiváltását: 


public delegate void EventHandlerDelegate(object sender, TestEventArgs e); 
public event EventHandlerDelegate TestStatusChange; 

priváté void OnStatusChangeQ 

{ 

if (TestStatusChange != null) 

{ 

TestStatusChange(this, new TestEventArgs("Az osztály állapota megváltozott")); 

} 

} 


A sender paraméternek a this-szel adjuk meg az értékét, ezután explicit konverzióval visszakaphatjuk belőle a 
küldő példányt (az első paraméter szintén konvenció szerint minden esetben object típusú lesz, mivel ugyanazt 
az eseményt használhatjuk különböző osztályokkal). 

Még módosítsuk az eseménykezelőt is: 


static public void Handler(object sender, TestEventArgs e) 

{ 

Console.WriteLine(e.Message); 

} 


A következő példában az események valódi hasznát fogjuk látni. Készítsünk egy egyszerű kliens-szerver 
alkalmazást (persze nem a hálózaton, csak szimuláljuk)! A kliensek csatlakozhatnak a szerverhez (ezután pedig 
kiléphetnek). A feladat, hogy minden ilyen eseményről küldjünk értesítést az összes csatlakozott kliensnek. 
Normális esetben a szerver osztálynak tárolnia kellene a kliensek hivatkozásait pl. egy tömbben. A probléma, 
hogy ez azért nem olyan egyszerű, hiszen gondoskodni kell arról, hogy a kilépett klienseket töröljük a listából, 
illetve a lista mérete is gondot jelenthet. Események alkalmazásával viszont nagyon egyszerű lesz a dolgunk. 
Készítsünk egy EventArgs osztályt, amely segítségünkre lesz az eseménykezelők értesítésében: 
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eláss ServerEventArgs : EventArgs 

{ 

public ServerEventArgs(string message) 
: base() 

{ 

this. Message = message; 

} 

public string Message { get; set; } 

} 


Most pedig a szervert készítjük el: 


eláss Server 

{ 

public delegate void ServerEvent(object sender, ServerEventArgs e); 
public event ServerEvent ServerChange; 

public Server() { } 

public void Connect(Client Client) 

{ 

this .ServerChange += Client.ServerMessageHandler; 

OnServerChange(string. Format("Felhasználó <{0}> csatlakozott!"., Client.Name)); 

} 

public void Disconnect(Client Client) 

{ 

OnServerChange(string. Format("Felhasználó <{0}> kilépett!", Client.Name)); 
this .ServerChange -= Client.ServerMessageHandler; 

} 

protected void OnServerChange(string message) 

{ 

if (ServerChange != null) 

{ 

ServerChange(this, new ServerEventArgs(message)); 

} 

} 

} 


Látható, hogy a kliensek kezelése nagyon egyszerű, mindössze egy műveletet kell elvégeznünk az eseményekre 
való feliratkozásért/leiratkozásért. Nézzük meg a kliens osztályt: 


eláss Client 

{ 

public Client(string name) 

{ 

Name = name; 

} 

public string Name { get; set; } 

public void ServerMessageHandler(object sender, ServerEventArgs e) 

{ 

Console.WriteLine( "{0} üzenetet kapott: {1}", 
this. Name, e.Message); 

} 

} 
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Végül a Main: 


static void Main(string[] args) 

{ 

Server server = new Server(); 

Client cl = new Client("3ózsi"); 

Client c2 = new Client("Béla"); 

Client c3 = new Client("Tomi"); 

server.Connect(cl); 
server.Connect(c2); 
server.Disconnect(cl); 
server.Connect(c3); 

Console .ReadKey(); 

} 
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Generikusok 


Az objektum-orientált programozás egyik alapköve a kód-újrafelhasználás, vagyis, hogy egy adott kódrészletet 
elég általánosra írjunk meg ahhoz, hogy minél többször felhasználhassuk. Ennek megvalósítására két eszköz áll 
rendelkezésünkre, az egyik az öröklődés, a másik pedig jelen fejezet tárgya, a generikusok. 


Generikus metódusok 

Vegyük a következő metódust: 


static public void Swap(ref int x, ref int y) 

{ 

int tmp = x; 
x = y; 

y = tmp; 

} 


Ha szeretnénk, hogy ez a metódus más típusokkal is működjön, akkor bizony sokat kell gépelnünk. Kivéve, ha 
írunk egy generikus metódust: 


static public void Swap<T>(ref T x, ref T y) 

{ 

T tmp = x; 

x = y; 
y = tmp; 

} 


A T fogja jelképezni az aktuális típust (lehet más nevet is adni neki, eredetileg a Template szóból jött), ezt 
generikus paraméternek hívják. Generikus paramétere csakis osztálynak, interfésznek vagy metódusnak lehet, 
és ebből többet is használhatnak. Ezután a metódust a hagyományos úton használhatjuk, a fordító felismeri, 
hogy melyik típust használjuk (ezt megadhatjuk mi magunk is explicite): 


int x = 10; 


int y = 20; 


Program.Swap<int>(ref x. 

ref y); 

Console.WriteLine("x == 

{0} és y == {1}", x, y); 

string sl = "alma"; 


string s2 = "dió"; 


Program . Swap<string> ( ref 

sl, ref s2); 

Console.WriteLine("sl == 

{0} és s2 == {1}", sl, s2); 


A C# generikusai hasonlítanak a C++ sablonjaira, de annál kevésbé hatékonyak, cserében sokkal biztonságosabb 
a használatuk. Két fontos különbség van a kettő közt: míg a C++ fordítási időben készíti el a specializált 
metódusokat/osztályokat, addig a C# ezt a műveletet futási időben végzi el. A másik eltérés az elsőből 
következik, mivel a C++ fordításkor ki tudja szűrni azokat az eseteket, amelyek hibásak, pl. összeadunk két 
tipust a sablonmetódusban, amelyeken nincs értelmezve összeadás. A C# ezzel szemben kénytelen az ilyen 
problémákat megelőzni, a fordító csakis olyan műveletek elvégzését fogja engedélyezni, amelyek 
mindenképpen működni fognak. A következő példa nem fog lefordulni: 


174 





static public T Sum<T>(T x, T y) 

{ 

return x + y; 

} 


Fordításkor csak azt tudja ellenőrizni, hogy létező típust adtunk-e meg, így nem tudhatja a fordító, hogy sikeres 
lesz-e a végrehajtás, ezért a fenti kód az összeadás miatt (nem feltétlenül valósítja meg minden típus) „rossz". 


Generikus osztályok 

Képzeljük el, hogy azt a feladatot kaptuk, hogy készítsünk egy verem típust, amely bármely típusra 
alkalmazható! Azt is képzeljük el, hogy még nem hallottunk generikusokról! így a legkézenfekvőbb megoldás, 
ha az elemeket egy object típusú tömbben tároljuk: 


eláss Stack 

{ 

object [] t; 
int pointer; 
readonly int size; 

public Stack(int capacity) 

{ 

t = new object[capacity]; 
size = capacity; 
pointer = 0; 

} 

public void Push(object item) 

{ 

if (pointer >= size) 

{ 

throw (new StackOverflowException("Tele van...")); 

} 

t[pointer++] = item; 

} 

public object Pop() 

{ 

if (pointer-- >= 0) { return t[pointer]; } 
pointer = 0; 

throw (new InvalidOperationException( "Üres ...")) ; 

} 

} 


Ezt most a következőképpen használhatjuk: 


static void Main(string[] args) 

{ 

Stack s = new Stack(10); 

fór (int i = 0; i < 10; ++i) 

{ 

s.Push(i); 

} 

fór (int i = 0; i < 10; ++i) 

{ 
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Console. WriteLine( (int) s.Pop()); 

} 

Console .ReadKey(); 


Működni működik, de se nem hatékony, se nem kényelmes. A hatékonyság az érték/referenciatípusok miatt 
csökken jelentősen (Id. boxing/unboxing), a kényelem pedig amiatt, hogy mindig figyelni kell, épp milyen 
típussal dolgozunk, nehogy olyan kasztolással éljünk, ami kivételt dob. 

Ezeket a problémákat könnyen kiküszöbölhetjük, ha generikus osztályt készítünk: 


eláss Stacl«T> 

{ 

T[] t; 

int pointer; 
readonly int size; 

public Stack(int capacity) 

{ 

t = new T[capacity]; 
size = capacity; 
pointer = 0; 

} 

public void Push(T item) 

{ 

if (pointer >= size) 

{ 

throw (new StackOverflowException("Tele van...")); 

} 

t[pointer++] = item; 

} 

public object Pop() 

{ 

if (pointer-- >= 0) 

{ 

return t[pointer]; 

} 

pointer = 0; 

throw (new InvalidOperationException( "Üres ...")) ; 

} 

} 


Ezután akármelyik típuson könnyen használhatjuk: 


static void Main(string[] args) 

{ 

Stack<int> s = new Stack<int>(10); 

fór (int i = 0; i < 10; ++i) 

{ 

s.Push(i); 

} 

fór (int i = 0; i < 10; ++i) 

{ 

Console. WriteLine(s.Pop()); 

} 
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Console .ReadKey(); 

} 


Generikus megszorítások 


Alapértelmezetten egy generikus paraméter bármely típust jelképezhet. A deklarációnál azonban kiköthetünk 
megszorításokat a paraméterre. Ezeket a where kulcsszóval vezetjük be: 


where T 

alaposztály 

where T 

interfész 

where T 

osztály 

where T 

struktúra 

where T 

new( ) 

where T 

ü 


Az utolsó két sor magyarázatra szorul. A new() megszorítás olyan osztályra utal, amely rendelkezik 
alapértelmezett konstruktorral. Az U pedig ebben az esetben egy másik generikus paramétert jelöl, vagyis T 
olyan típusnak felel meg, amely vagy U -ból származik, vagy egyenlő' vele. 

Nézzünk néhány példát: 


eláss Test<T> 

where T : eláss 


{ 

} 


Ezt az osztályt csak referenciatípusú generikus paraméterrel példányosíthatjuk, minden más esetben fordítási 
hibát kapunk. 


eláss Test<T> 

where T : struct 


{ 


} 


Ez pedig épp az ellenkezője, értéktípusra van szükség. 


eláss Test<T> 

where T : IEnumerable 

{ 

} 


Most csakis IEnumerable interfészt megvalósító típussal példányosíthatjuk az osztályt. 

eláss Base { } 

eláss Derived : Base { } 

eláss Test<T> 

where T : Base 

{ 

} 
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Ez már érdekesebb. Ez a megszorítás a generikus paraméter ősosztályára vonatkozik, vagyis példányosíthatunk 
a Base és a Derived típussal is. 


eláss DefConst 

{ 

public DefConst() { } 

} 

eláss Test<T> 

where T : new() 

{ 

} 


Itt olyan típusra van szükségünk, amely rendelkezik alapértelmezett konstruktorral, a DefConst osztály is ilyen. 

eláss Base { } 

eláss Derived : Base { } 

eláss TesteTj U> 
where T : U 

{ 

} 


Most T típusának olyannak kell lennie, amely implicit módon konvertálható U típusára, vagyis T vagy 
megegyezik U-val, vagy belőle származik: 


TestxDerived, Base> ti = new TesteDerived, Base>(); // ez jó 
TesteBase, Derived> t2 = new TesteBase, Derived>(); // ez nem jó 


Értelemszerűen írhattunk volna <Base, Base>-t vagy <Derived, Derived>-et is. 


Öröklődés 


Generikus osztályból származtathatunk is, ekkor vagy az ősosztály egy specializált változatát vesszük alapul, 
vagy a nyers generikus osztályt: 


eláss Base<T> 

{ 

} 

eláss Derived<T> : Base<T> 

{ 

} 

//vagy 

eláss IntDerived : Base<int> 

{ 

} 
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Statikus tagok 


Generikus típusok esetében minden típushoz külön statikus tag tartozik: 


using System; 


namespace TestApp 
{ 

eláss Test<T> 

{ 

static public int Value; 

} 


eláss Program 
{ 

static void Main(string[] args) 

{ 

Test<int> .Value = 10; 

Test<string> .Value = 20; 


Console. WriteLine( Teste int >.Value); // 
Console. WriteLine( Test <string> .Value); 

10 

// 20 

Console. ReadKeyQ; 

} 

} 

} 



Generikus gyűjtemények 

A C# 2.0 bevezetett néhány hasznos generikus adatszerkezetet, többek közt listát és vermet. A következőkben 
megvizsgálunk közülük néhányat. Ezek a szerkezetek a System.Collections.Generic névtérben találhatóak. 

List<T> 

A List<T> az ArrayList generikus, erősen típusos megfelelője. A legtöbb esetben a List<T> hatékonyabb lesz az 
ArrayList-nél, emellett pedig típusbiztos is. 

Amennyiben értéktípussal használjuk a List<T>-t, az alapértelmezetten nem igényel bedobozolást, de 
rendelkezik néhány olyan művelettel, amely viszont igen, ezek főleg a kereséssel kapcsolatosak. Azért, hogy az 
ebből következő teljesítményromlást elkerüljük, a használt értéktípusnak meg kell valósítania az IComparable 
és az lEquatable interfészeket (a legtöbb beépített egyszerű (érték)típus ezt meg is teszi) (ezeket az 
interfészeket az összes többi gyűjtemény is igényli). 


using System; 

using System.Collections.Generic; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

List<int> üst = new List<int>(); 

fór (int i = 0; i < 10; ++i) 

{ 

üst. Add(i); 
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} 

foreach (int item in üst) 

{ 

Console.WriteLine(item); 

} 

Console .ReadKey(); 

} 

} 

} 


Az Add metódus a lista végéhez adja hozzá a paraméterként megadott elemet, hasonlóan az ArrayList-hez. 
Használhatjuk rajta az indexelő' operátort is. 

A lista elemeit könnyen rendezhetjük a Sort metódussal (ez a metódus igényli, hogy a lista típusa megvalósítsa 
az IComparable interfészt): 


using System; 

using System.Collections.Generic; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

List<int> üst = new List<int>(); 

Random r = new Random(); 

fór (int i = 0; i < 10; ++i) 

{ 

üst.Add(r .Next(100)); 

Console. Write("{0}, ", üst[i]); // rendezetlen elemek 

} 

Console.WriteLine(); 
üst.Sort(); 

foreach (int item in üst) 

{ 

Console. Write("{0}, ", item); // rendezett elemek 

} 

Console .ReadKey(); 

} 

} 

} 


Kereshetünk is az elemek között a BinarySearch metódussal, amely a keresett objektum indexét adja vissza: 


using System; 

using System.Collections.Generic; 

namespace TestApp 

{ 

eláss Program 

{ 
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static void Main(string[] args) 

{ 

List<string> üst = new List<stning>( ) 

{ 

"alma"., "dió"., "körte"., "barack" 




} 


} 


Console.WriteLine(üst[üst.BinarySearch(" körte") ]); 
Console .ReadKey(); 


Megkereshetjük az összes olyan elemet is, amely eleget tesz egy feltételnek a Find és FindAII metódusokkal. 
Előbbi az első, utóbbi az összes megfelelő példányt adja vissza egy List<T> szerkezetben: 


using System; 

using System.Collections.Generic; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

List<int> üst = new List<int>(); 

Random r = new Random(); 

fór (int i = 0; i < 100; ++i) 

{ 

üst. Add(r .Next (1000)); 

} 

Console. WriteLine( "Az első páros szám a listában: {0}", 
üst.Find(delegate(int item) 

{ 

return item % 2 == 0; 

})); 

List<int> evenList = üst. FindAll(delegate(int item) 

{ 

return item % 2 == 0; 

}); 

Console. WriteLine( "Az összes páros elem a listában:"); 

evenList. ForEach(delegate(int item) 

{ 

Console.WriteLine(item); 

}); 

Console .ReadKey(); 

} 

} 

} 


A feltételek megadásánál és a páros számok listájának kiíratásánál névtelen metódusokat használtunk. 
Újdonságot jelent a listán metódusként hívott foreach ciklus. Ezt a C# 3.0 vezette be, és az összes generikus 
adatszerkezet rendelkezik vele, lényegében teljesen ugyanúgy működik, mint egy „igazi" foreach. 
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Paramétereként egy void Method(T item) szignatúrájú metódust (vagy névtelen metódust) vár, ahol T a lista 
elemeinek típusa. 

SortedList<T, U> és SortedDictionary<T, U> 

A SortedList<T, U> kulcs-érték párokat tárol el, és a kulcs alapján rendezi is őket: 


using System; 

using System.Collections.Generic; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

SortedList<string, int> üst = new SortedList<string, int>(); 

list.Add("egy"j 1); 
üst .Add( "kettő", 2); 
üst .Add( "három", 3); 

Console .ReadKey(); 

} 

} 

} 


A lista elemei tulajdonképpen nem a megadott értékek, hanem a kulcs-érték párokat reprezentáló 
KeyValuePair<T, U> objektumok. A lista elemeinek eléréséhez is használhatjuk ezeket: 


foreach (KeyValuePair<string, int> item in üst) 

{ 

Console. WriteLine( "Kulcs == {0}, Érték == {1}"., 
item.Key, item.Value); 

} 


A lista kulcsai csakis olyan típusok lehetnek, amelyek megvalósítják az IComparable interfészt, hiszen ez alapján 
történik a rendezés. Ha ez nincs így, akkor mi magunk is definiálhatunk ilyet, részletekért Id. az Interfészek 
fejezetet. 

A listában minden kulcsnak egyedinek kell lennie (ellenkező esetben kivételt kapunk), illetve kulcs helyén nem 
állhat null érték (ugyanez viszont nem igaz az értékekre). 

A SortedDictionary<T, U> használata gyakorlatilag megegyezik a SortedList<T, U>-val, a különbség a 
teljesítményben és a belső szerkezetben van. 

A SD új (rendezetlen) elemek beszúrását gyorsabban végzi, mint a SL (0(Log n) és O(n)). Előre rendezett 
elemek beszúrásánál pont fordított a helyzet. Az elemek közti keresés mindkét szerkezetben 0(Log n). 
Ezenkívül a SL kevesebb memóriát használ fel. 

DictionarycT, U> 

A SortedDictionary<T, U> rendezetlen párja a DictionarycT, U>: 


using System; 

using System.Collections.Generic; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[] args) 
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Dictionary<string, int> üst = new Dictionary<string, int>(); 

list.Add("egy"j 1); 
üst.Add( "kettő", 2); 
üst.Add( "három" , 3); 

foreach (KeyValuePair<stringj int> item in üst) 

{ 

Console. WriteLine("Kulcs == {0}, Érték == {1}"., 
item.Key, item.Value); 

} 

Console .ReadKey(); 

} 

} 

} 


Teljesítmény szempontjából a Dictionary<T, U> mindig jobb eredményt fog elérni (egy elem keresése kulcs 
alapján 0(1)), ezért ha nem fontos szempont a rendezettség, akkor használjuk ezt! 

LinkedList<T> 

A LinkedList<T> egy kétirányú láncolt lista. Egy elem beillesztése illetve eltávolítása 0(1) nagyságrendű 
művelet. A lista minden tagja különálló objektum, egy-egy LinkedListNode<T> példány. A LinkedListLNode<T> 
Next és Previous tulajdonságai a megeló'zó' illetve a következő' elemre mutatnak. 

A lista First tulajdonsága az első, Last tulajdonsága pedig az utolsó tagra mutat. Elemeket az AddFirst (első 
helyre szúr be) és AddLast (utolsó helyre tesz) metódusokkal tudunk beilleszteni. 


using System; 

using System.Collections.Generic; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

LinkedList<string> üst = new LinkedList<string>( ); 

üst. Add Last ("alma"); 
üst .Add Last ( "dió") ; 
üst .Add Last ( "körte") ; 
üst .AddFirst ( "narancs") ; 

LinkedListNode<string> current = üst.First; 

while (current != null) 

{ 

Console. WriteLine(current.Value); 
current = current.Next; 

} 

Console .ReadKey(); 

} 

} 

} 


Ebben a példában bejárunk egy láncolt listát, a kimeneten a „narancs" elemet látjuk majd első helyen, mivel őt 
az AddFirst metódussal helyeztük be. 
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ReadOnlyCollection<T> 

Ahogy a nevéből látszik, ez az adatszerkezet az elemeit csak olvasásra adja oda. A listához nem adhatunk új 
elemet sem (ezt nem is támogatja), csakis a konstruktorban tölthetjük fel. 


using System; 

using System.Collections.Generic; 

using System.Collections.ObjectModel; // ez is kell!! 

namespace TestApp 
{ 


eláss Program 

{ 

static void Main(string[ ] args) 

{ 

List<string> üst = new List<string>( ) 

{ 

"alma"., "körte"., "dió" 


}; 


ReadOnlyCollection<string> roc = new ReadOnlyCollection<string>(list); 

foreach (string item in roc) 

{ 

Console.WriteLine(item); 

} 


} 


} 


} 


Console .ReadKey(); 


Generikus interfészek, delegate-ek és események 

A legtöbb hagyományos interfésznek létezik generikus változata is. Például az lEnumerable és lEnumerator is 
ilyen: 


eláss MyClass<T> : IEnumerable<T>, IEnumerator<T> 

{ 

} 


Ekkor a megvalósítás teljesen ugyanúgy működik, mint a hagyományos esetben, csak épp használnunk kell a 
generikus paraméter(eke)t. 

A generikus adatszerkezetek (többek között) a generikus ICollection, IList és IDictionary interfészeken 
alapulnak, így ezeket megvalósítva akár mi magunk is létrehozhatunk ilyet. 

Az interfészekhez hasonlóan a delegate-ek és események is lehetnek generikusak. Ez az ő esetükben egyáltalán 
nem jár semmilyen „extra" kötelezettséggel. 


Kovariancia és kontravariancia 

Nézzük a következő „osztályhierarchiát": 


eláss Person 

{ 

public int Age; 
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} 

eláss Student : Person 

{ 

public string Name { get; set; } 

} 


A polimorfizmus elve miatt minden olyan helyen, ahol egy Person objektum használható, ott egy Student 
objektum is megfelel, legalábbis elvileg. Lássuk, a következő kódot: 


List<Student> studentList = new List<Student>(); 
List<Person> personList = studentList; 


A fenti két sor, pontosabban a második nem fordul le, mivel a .NET nem tekinti egyenlőnek a generikus 
paramétereket, még akkor sem, ha azok kompatíbilisak lennének. Azt mondjuk, hogy a generikus paraméterek 
nem kovariánsak (covariance). A dolog fordítottja is igaz, vagyis nincs kompatibilitás az általánosabb típusról a 
szőkébbre sem, nem kontravariánsak (contravariance). 

Miért van ez így? Képzeljük el azt a helyzetet, amikor a fenti osztályokat kiegészítjük még egy Teacher 
osztállyal, amely szintén a Person osztályból származik! Ha a generikus paraméterek kovariánsan 
viselkednének, akkor lehetséges lenne Student és Teacher objektumokat is egy listába tenni, ez pedig azzal a 
problémával jár, hogy lehetséges lenne egy elem olyan tulajdonságát módosítani, amellyel nem rendelkezik, ez 
pedig nyilván hibát okoz (persze típusellenőrzéssel ez is áthidalható, de ezzel az egész generikus adatszerkezet 
értelmét vesztené). 

A .NET 4.0 bevezeti a kovariáns és kontravariáns típusparamétereket, úgy oldva meg a fent vázolt problémát, 
hogy a kérdéses típusok csak olvashatóak, illetve csak írhatóak lesznek. A következő példában egy generikus 
delegate segítségével nézzük meg az új lehetőségeket (új lístaszerkezetet írni bonyolultabb lenne) (a példa 
megértéséhez szükség van a lambda kifejezések ismeretére): 


eláss Program 

{ 

delegate void Method<T>(); 

static void Main(string[] args) 

{ 

Method<Student> ml = () => new Student(); 
Method<Person> m2 = ml; 

Console. ReadKey(); 

} 

} 


A fenti kód nem fordul le, módosítsuk a delegate deklarációját: 


delegate void Method<out T>(); 


Most viszont minden működik, hiszen biztosítottuk, hogy minden típust megfelelően kezeljünk. A .NET 
beépített generikus típusai már fel vannak készítve a fenti helyzetre, szóval írhatjuk a következőt: 


IEnumerable<Student> sie = new List<Student>() 

{ 

new Student() { Name = "Szandra", Age = 22 }, 
new Student() { Name = "István", Age = 26 }, 

}; 

IEnumerable<Person> pie = sie; 

foreach (Person person in pie) 

{ 
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Console.WriteLine(person.Age); 

} 


Most lássuk a kontravarianciát! Itt már lényegesen „természetesebb" dologról van szó, hiszen hasonlót 
láthattunk, amikor öröklődéssel foglalkoztunk. 


eláss Program 

{ 

delegate void Methodcin T>(T t); 

static void Main(string[] args) 

{ 

Method<Person> ml = (person) => Console .WriteLine(person.Age); 

Method<Student> m2 = ml; 

Student s = new StudentQ { Age = 22, Name = "Szandra" }; 

ml(s)j // 22 
m2(s); // 22 

Console. ReadKeyQ; 

} 

} 
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Lambda kifejezések 


A C# 3.0 bevezeti a lambda kifejezéseket. Egy lambda kifejezés gyakorlatilag megfelel egy névtelen metódus 
„civilizáltabb", elegánsabb változatának (ugyanakkor első ránézésre talán ijesztőbb, de ha megszokta az ember, 
sokkal olvashatóbb kódot eredményez). 

Minden lambda kifejezés tartalmazza az ún. lambda operátort (=>), ennek jelentése nagyjából annyi, hogy 
„legyen". Az operátor bal oldalán a bemenő változók, jobb oldalán pedig a bemenetre alkalmazott kifejezés áll. 
Mivel névtelen metódus, ezért egy lambda kifejezés állhat egy delegate értékadásában is, elsőként ezt nézzük 
meg: 


using System; 

eláss Program 

{ 

public delegate int IntFunc(int x); 

static void Main(string[] args) 

{ 

IntFunc func = (x) => (x * x); 
Console. WriteLine(func(10)); // 100 
Console. ReadKeyQ; 

} 

} 


Egy olyan metódusra van tehát szükség, amely egy int típusú bemenő paramétert vár, és ugyanilyen típust ad 
vissza. A lambda kifejezés bal oldalán a bemenő paraméter (x), jobb oldalán pedig a visszadott értékről 
gondoskodó kifejezés (x * x) áll. A bemenő paraméternél nem kell (de lehet) explicit módon jeleznünk a típust, 
azt a fordító magától „kitalálja" (a legtöbb esetre ez igaz, de néha szükség lesz rá, hogy jelöljük a típust). 
Természetesen nemcsak egy bemenő paramétert használhatunk, a következő példában összeszorozzuk a 
lambda kifejezés két paraméterét: 


using System; 

eláss Program 

{ 

public delegate int IntFunc2(int x, int y); 

static void Main(string[] args) 

{ 

IntFunc2 func = (x, y) => (x * y); 
Console. WriteLine(func(10j 2)); // 20 
Console. ReadKey(); 

} 

} 


Generikus kifejezések 

Generikus kifejezéseknek (tulajdonképpen ezek generikus delegate-ek) is megadhatunk lambda kifejezéseket, 
amelyek nem igénylik egy előzőleg definiált delegate jelenlétét, ezzel önálló lambda kifejezéseket hozva létre 
(ugyanakkor a generikus kifejezések kaphatnak névtelen metódusokat is értékül). Kétféle generikus kifejezés 
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létezik: a Func, amely adhat visszatérési értéket és az Action, amely nem (void) (lásd: függvény és eljárás). 
Elsőként a Func-ot vizsgáljuk meg: 


using System; 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Funccint, int> func = (x) => (x * x); 
Console. WriteLine(func(10)); // 100 
Console. ReadKeyQ; 

} 

} 


A generikus paraméterek között (balról jobbra) utolsó helyen mindig a visszatérési érték áll, előtte pedig a 
bemenő paraméterek (maximum négy) kapnak helyet. 


using System; 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Funccint., int, bool> func = (x, y) => (x > y); 
Console. WriteLine(func(10, 5)); // True 
Console. ReadKeyQ; 

} 

} 


Most megnéztük, hogy az első paraméter nagyobb-e a másodiknál. Értelemszerűen a lambda operátor jobb 
oldalán lévő kifejezésnek megfelelő típust (bool) kell eredményeznie, ezt a fordító ellenőrzi. 

A Func minden esetben rendelkezik legalább egy paraméterrel, mégpedig a visszatérési érték típusával, ez 
biztosítja, hogy mindig legyen visszatérési érték. 


using System; 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Func<bool> func = () => true; 
Console. WriteLine(func()); // True 
Console. ReadKeyQ; 

} 

} 


A Func párja az Action, amely szintén maximum négy bemenő paramétert kaphat, de nem lehet visszatérési 
értéke: 
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using System; 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Action<int> act = (x) => Console. WriteLine(x); 
act(10); 

Console. ReadKeyQ; 

} 

} 


Kifejezésfák 

Generikus kifejezések segítségével felépíthetünk kifejezésfákat, amelyek olyan formában tárolják a kifejezésben 
szereplő adatokat és műveleteket, hogy futási időben a CLR ki tudja azt értékelni. Egy kifejezésfa egy generikus 
kifejezést kap generikus paraméterként: 


using System; 

using System.Linq.Expressions; // ez a névtér kell 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Expression<Func<intj int, bool>> expression = (x, y) => (x > y); 
Console. WriteLine(expression.Compile().Invoke(10j 2)); // True 
Console. ReadKeyQ; 

} 

} 


A programban először IL kódra kell fordítani (Compile), csak azután hívhatjuk meg. 


Lambda kifejezések változóinak hatóköre 

Egy lambda kifejezésben hivatkozhatunk annak a metódusnak a paramétereire és lokális változóira, amelyben 
definiáltuk. A külső változók akkor értékelődnek ki, amikor a delegate ténylegesen meghívódik, nem pedig a 
deklaráláskor, vagyis az adott változó legutolsó értékadása számít majd. A felhasznált változókat inicializálni 
kell, mielőtt használnánk egy lambda kifejezésben. A lambda kifejezés fenntart magának egy másolatot a lokális 
változóból/paraméterből, még akkor is, ha az időközben kifut a saját hatóköréből: 


using System; 

eláss Test 

{ 

public Action<int> act; 

public void Method() 

{ 

int local = 11; 

act = (x) => Console. WriteLine(x * local); 
local = 100; 

} 
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} 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Test t = new Test(); 
t.Method(); 
t.act(100); 

Console. ReadKeyQ; 

} 

} 


Ez a program 10000-et fog kiírni, vagyis valóban a lokális változó legutolsó értékét használta a lambda kifejezés. 

A lokális változók és paraméterek módosíthatóak egy lambda kifejezésben. A lambda kifejezésben létrehozott 
változók ugyanúgy viselkednek, mint a hagyományos lokális változók, a delegate minden hívásakor új példány 
jön létre beló'lük. 


Névtelen metódusok kiváltása lambda kifejezésekkel 

Lambda kifejezést használhatunk minden olyan helyen, ahol névtelen metódus állhat. Nézzük meg pl., hogy 
hogyan használhatjuk így a List<T> típust: 


using System; 

using System.Collections.Generic; 

eláss Program 

{ 

static void Main(string[] args) 

{ 

List<int> üst = new List<int>(); 

fór (int i = 1; i < 10; ++i) 

{ 

üst. Add(i); 

} 

int result = üst.Find((item) => (item % 2 == 0)); 

Console. WriteLine( "Az első páros szám: {0}"., result); 
List<int> oddList = üst.FindAll((item) => (item % 2 != 0)); 
Console. WriteLine( "Az összes páratlan szám:"); 
oddList.ForEach((item) => Console. WriteLine(item)); 

Console. ReadKeyQ; 

} 

} 


Eseménykezeló't is írhatunk így: 


190 




eláss Test 

{ 

public event EventHandler TestEvent; 

public void OnTestEventQ 

{ 

if (TestEvent != null) 

{ 

TestEvent(thiSj null); 

} 

} 

} 


Az EventHandler általános delegate-et használtuk az esemény deklarációjánál. Az esemény elindításánál nincs 
szükségünk most EventArgs objektumra, ezért itt nyugodtan használhatunk null értéket. 

Most nézzük a programot: 


static void Main(stning[] args) 

{ 

Test t = new Test(); 

t.TestEvent += (sender, e) => 

{ 

Console. WriteLine( "Eseménykezelő! ") ; 

}; 

t.OnTestEventQ; 

Console .ReadKey(); 

} 


Lambda kifejezés helyett ún. lambda állítást (ezt blokkal jelöljük ki) írtunk, így akár többsoros utasításokat is 
adhatunk. 
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Unsafe kód 


A .NET platform legnagyobb eltérése a natív nyelvektől a memória kezelésében rejlik. A menedzselt kód nem 
enged közvetlen hozzáférést a memóriához, vagyis annyi a dolgunk, hogy megmondjuk, hogy szeretnénk egy 
ilyen és ilyen típusú objektumot, a rendszer elkészíti nekünk, és kapunk hozzá egy referenciát, amelyen 
keresztül elérjük. Nem fogjuk tudni, hogy a memóriában hol van és nem is tudjuk áthelyezni. Épp ezért a 
menedzselt kód biztonságosabb, mint a natív, mivel a fentiek miatt egész sor hibalehetőség egész egyszerűen 
eltűnik. Ennek azonban ára van, méghozzá a sebesség, de ezt behozzuk a memória gyorsabb 
elérésével/kezelésével, ezért a két módszer között lényegében nincs teljesítménybeli különbség. 

Vannak azonban helyzetek, amikor igenis fontos, hogy közvetlenül elérjük a memóriát: 

• A lehető legjobb teljesítményt szeretnénk elérni egy rendkívül számításigényes feladathoz (pl.: 
számítógépes grafika). 

• .NET-en kívüli osztálykönyvtárakat akarunk használni (pl.: Windows API hívások). 

A C# a memória direkt elérését mutatókon (pointer) keresztül teszi lehetővé. Ahhoz, hogy mutatókat 
használhassunk, az adott metódust, osztályt, adattagot vagy blokkot az unsafe kulcsszóval kell jelölnünk (ez az 
ún. unsafe context). Egy osztályon belül egy adattagot vagy metódust jelölhetünk unsafe módosítóval, de ez 
nem jelenti azt, hogy maga az osztály is unsafe lenne. Nézzük a következő példát: 


using System; 

eláss Test 

{ 

public unsafe int* x; 

} 

eláss Program 

{ 

static void Main(string[] args) 

{ 

unsafe 

{ 

Test t = new Test(); 
int y = 10; 
t.x = &y; 

Console.WriteLine(*t.x); 

} 

Console. ReadKey(); 

} 

} 


Először deklaráltunk egy unsafe adattagot, méghozzá egy int típusra mutató pointert. A pointer típus az érték- 
és referenciatípusok mellett a harmadik tipuskategória. A pointerek nem származnak a System.Object-ből és 
konverziós kapcsolat sincs közöttük (bár az egyszerű numerikus típusokról létezik explicit konverzió). 
Értelemszerűen boxing/unboxing sem alkalmazható rajtuk. Egy pointer mindig egy memóriacímet hordoz, 
amely memóriaterületen egy teljesen normális objektum van. Ebből következően a fenti deklarációban nem 
adhatok azonnal értéket az unsafe pointernek, mivel numerikus értékadás esetén nem fordul le a program 
(hiszen nem egy int objektumról van szó), más objektum memóriacímét viszont nem tudom. Sebaj, erre való az 
ún. „címe-operátor" (&), amellyel átadhatom egy hagyományos objektum címét. 

A programban ki akarjuk írni a memóriaterületen lévő objektum értékét, ezt a dereference operátorral (*) 
tehetjük meg. Ez visszaadja a mutatott értéket, míg ha magát a változót használjuk, az „csak" a memóriacímet. 
A memóriacím a memória egy adott byte-jára mutat (vagyis a pointer növelése/csökkentése a pointer 
típusának megfelelő mennyiségű byte-tal rakja odébb a mutatót, tehát egy int pointer esetén ez négy byte 
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lesz), amely az adott objektum kezdőcíme. A pointer úgy tudja visszaadni az értékét, hogy tudja, mekkora 
méretű az objektum (pl. egy int pointer egy 32 bites - 4 byte méretű - területet vesz majd elő). 


A programot parancssorból a /unsafe kapcsolóval fordíthatjuk le, Visual Stúdió esetén jobb klikk a projecten, 
Properties ablak, és a Build fülön jelöljük meg az „Allow unsafe code" négyzetet. 

esc /unsafe main.cs 


A megfelelő explicit konverzióval a memóriacímet is lekérhetjük: 


using System; 

eláss Program 

{ 

static void Main(string[] args) 

{ 

unsafe 

{ 

int x = 10; 
int* y = &x; 

Console.WriteLine((int)y); 

} 

Console. ReadKey(); 

} 

} 


Pointer csakis a beépített numerikus típusokra (beleértve a char is), logikai típusokra, felsorolt típusokra, más 
pointerekre, illetve minden olyan általunk készített struktúrára hivatkozhat, amely nem tartalmaz az eddig 
felsoroltakon kívül mást. Ezeket a típusokat összefoglaló néven unmanaged típusoknak nevezzük. 

Explicit konverzió létezik szűkebb pointer típusról tágabb típusra, fordított eset fordítási hibát okoz. 
Ugyanakkor az előbbi eset elvileg definiálatlan eredménnyel járhat, a gyakorlatban azért működőképes. 


int 

x = 10; 


byte y = 20; 


int* 

pl = &x; // ez jó 


pl = 

(int*)&y; // ez nem biztos. 

hogy jó, de működik 

pl = 

(byte*)&x; // ez már le sem 

fordul 


Implicit konverzió van viszont bármely pointer típusról 
használható a dereference operátor: 

a void* univerzális pointer típusra. A void*-on nem 

int x = 10; 
void* pl = &x; 


Console .WriteLine(*( (int*)pl) ); // 10 


Egy struktúrára is hivatkozhatunk pointerrel, ekkor a tagjait kétféleképpen érhetjük el: vagy a mutatón 
keresztül, vagy a nyíl (->) operátorral, amely tulajdonképpen az előbbi rövidítése: 


using System; 


struct Test 

{ 

public int x; 

} 
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eláss Program 

{ 

static void Main(string[] args) 

{ 

unsafe 

{ 

Test t = new Test(); 
t.x = 10; 

Test* p = &t; 

Console.WriteLine((*p).x); // 10 
Console. WriteLine(p->x); // 10 

} 

Console. ReadKeyQ; 

} 

} 


Fix objektumok 

Normális esetben a szemétgyűjtő a memória töredezettségmentesítése érdekében mozgatja az objektumokat a 
memóriában. Egy pointer azonban mindig egy fix helyre mutat, hiszen a mutatott objektum címével dolgozunk, 
ami pedig nem fog frissülni. Ez néhány esetben gondot okozhat (pl. amikor hosszabb ideig van a memóriában a 
mutatott adat, pl. valamilyen erőforrás). Ha szeretnénk, hogy az objektumok a helyükön maradjanak, akkor a 
fixed kulcsszót kell használnunk. 

Mielőtt jobban megnéznénk a fixed-et, vegyük szemügyre a következő forráskódot: 


int[] array = new int[] { 1, 3, 4, 6 , 7 }; 
int* p = &array; 


Ez a két sor fordítási hibával jár. Bár a tömbök referenciatípusok, mégis kivételt képeznek, mivel használhatunk 
rajtuk pointert, igaz nem az eddig látott módon (valamint a tömb elemeinek unmanaged típusnak kell lenniük). 
Referenciatípuson belül deklarált értéktípusok esetén (ilyenek a tömbelemek is) fixálni kell az objektum 
helyzetét, hogy a GC ne mozdíthassa el. A következő kód már működni fog: 


using System; 

eláss Program 

{ 

static void Main(string[] args) 

{ 

unsafe 

{ 

int [] array = new int[] { 1, 3, 4, 6, 7 }; 

fixed (int* p = array) 

fór (int i = 0 ; i < 5; ++i) 

{ 

Console. WriteLine(*(p + i)); 

} 

} 

Console. ReadKeyQ; 

} 

} 
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Natív DLL kezelés 


Előfordul, hogy olyan metódust akarunk hívni, amelyet egy natív (pl. C++ nyelven írt) külső könyvtár tartalmaz. 
A következő példában egy Windows API metódust hívunk meg, amely megjelenít egy MessageBox-ot. Ahhoz, 
hogy ezt meg tudjuk tenni, elsősorban ismernünk kell az eredeti metódus szignatúráját, ehhez szükségünk lesz 
pl. a Win32 Programmers Reference című dokumentációra, amelyet letölthetünk: 

http://www.winasm.net/win32hlp.html 

Keressük ki a MessageBox metódust, és a következőt fogjuk látni: 


int MessageBox( 

HWND hWnd, // handle of owner window 

LPCTSTR lpText, // address of text in message 
LPCTSTR lpCaption, // address of title of 

UINT uType // style of message box 

); 

box 

message box 

Ezenkívül még tudnunk kell azt is, hogy melyik DLL tárolja az adott függvényt, ez pedig jelen esetben a 
user32.dll lesz. Mindent tudunk, készítsük el a programot! A függvény importálásához a Dlllmport attribútumot 
fogjuk használni: 

using System; 

using System.Runtime.InteropServices; // ez a névtér szükséges 

public eláss API 
{ 

[Dlllmport ("u ser32.dll") ] 

public static extern int MessageBox(int hWnd, 
string text, string caption, uint type); 

} 


eláss Program 
{ 

static void Main(string[] args) 

{ 

API .MessageBox(0, "Hello!", "Nincs", 0); 

} 

} 



Az attribútumnak meg kell adnunk a könyvtár nevét (user32.dll), valamint a metódus-deklarációt az extern 
kulcsszóval kell jelölnünk, hogy tudassuk a fordítóval, hogy a függvényt egy küldő forrásból kell előkerítenie. 

A forráskódot a szokásos módon fordítjuk, és ha elindítjuk, akkor a következőt kell látnunk: 
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Többszálú alkalmazások 


Egy Windows alapú operációs rendszerben minden futtatható állomány indításakor egy ún. process jön létre, 
amely teljes mértékben elkülönül az összes többitó'l. Egy processt az azonosítója (PID - Process ID) alapján 
különböztetünk meg a többitó'l. 

Minden egyes process rendelkezik egy ún. fő szállal (primary- vagy main thread), amely a program belépési 
pontja (Id. Main). 

Azokat az alkalmazásokat, amelyek csak fő szállal rendelkeznek, thread-safe alkalmazásoknak nevezzük, mivel 
csak egy szál fér hozzá az összes erőforráshoz. Ugyanakkor ezek az alkalmazások hajlamosak „elaludni", ha egy 
komplexebb feladatot hajtanak végre, hiszen a fő szál ekkor nem tud figyelni a felhasználótól érkező akciókra 
(pl. billentyűlenyomás). 

Az ilyen helyzetek elkerülésére a Windows (és a .NET) lehetővé teszi másodlagos szálak (ún. worker thread) 
hozzáadását a fő szálhoz. Az egyes szálak (a processekhez hasonlóan) önállóan működnek a folyamaton belül, 
és „versenyeznek" az erőforrások használatáért (concurrent access). 

Jó példa lehet a szálkezelés bemutatására egy szövegszerkesztő használata: amíg kinyomtatunk egy 
dokumentumot (egy mellékszállal), az alkalmazás fő szála továbbra is figyeli a felhasználótól érkező 
utasításokat. 

A többszálú programozás legnagyobb kihívása a szálak és feladataik megszervezése, az erőforrások elosztása. 

Fontos megértenünk, hogy valójában a többszálúság a számítógép által nyújtott illúzió, hiszen a processzor 
egyszerre csak egy feladatot tud végrehajtani (bár ma már szinte csak többmagos rendszerek léteznek, de 
gondoljunk bele, hogy amikor hozzá sem nyúlunk a számítógéphez is ötven-száz szál fut), így el kell osztania az 
egyes feladatok közt a processzoridőt (ezt a szálak prioritása alapján teszi) ez az ún. időosztásos (time slicing) 
rendszer. Amikor egy szálnak kiosztott idő lejár, akkor a futási adatait eltárolja az ún. Thread Local Storage-ben 
(ebből minden szálnak van egy), és átadja a helyet egy másik szálnak, amely - ha szükséges - betölti a saját 
adatait a TLS-ből, és elvégzi a feladatát. 

A .NET számos osztályt és metódust bocsát rendelkezésünkre, amelyekkel az egyes processeket felügyelhetjük, 
ezek a System.Diagnostics névtérben vannak. írjunk egy programot, amely kiírja az összes futó folyamatot és 
azonosítójukat: 


using System; 

using System.Diagnostics; // erre a névtérre szükség van 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Process[] processList = Process .GetProcesses(; 

foreach (Process process in processList) 

{ 

Console.WriteLine("PID: {0}, Process - név: {1}"., 
process.Id, process.ProcessName); 

} 

Console. ReadKeyQ; 

} 

} 


Amennyiben tudjuk a process azonosítóját, akkor használhatjuk a Process.GetProcessByld(azonosító) 
metódust is. 

A következő programunk az összes futó process minden szálát és azoknak adatait fogja kilistázni: 
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using System; 

using System.Diagnostics; // erre a névtérre szükség van 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Process[] processList = Process .GetProcesses( ".") ; 

foreach (Process process in processList) 

{ 

Console.WriteLine("A folyamat ({0}) szálai", 
process.ProcessName); 

ProcessThreadCollection ptc = process.Threads; 

foreach (ProcessThread thread in ptc) 

{ 

Console.WriteLine("Id: {0}, Állapot: {1}", 
thread.Id, thread.ThreadState); 

} 

} 

Console. ReadKeyQ; 

} 

} 


Lehetséges, hogy a program futásakor kivételt kapunk, hiszen a szálak listájába olyan szál is bekerülhet, amely a 
kiíráskor már befejezte futását (ez szinte mindig az Idle process esetében fordul elő, a meggondolás házi 
feladat, akárcsak a program kivételbiztossá tétele). 

A fenti osztályok segítségével remekül bele lehet látni a rendszer „leikébe", az MSDN-en megtaláljuk a fenti 
osztályok további metódusait, tulajdonságait, amelyek az „utazáshoz" szükségesek. 

A következő programunk a process-ek irányítását szemlélteti. Indítsuk el az Internet Explorert, várjunk öt 
másodpercet, és állítsuk le: 


using System; 

using System.Diagnostics; 

using System.Threading; // erre a névtérre szükség van 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Process explorer = Process.StartCiexplore.exe"); 

Thread.Sleep(5000); 

explorer.Kill(); 

Console. ReadKeyQ; 

} 

} 


Egyúttal felhasználtuk az első igazi szálkezeléshez tartozó metódusunkat is, a Thread osztály statikus Sleep 
metódusát (a Thread osztály a System.Threading névtérben található). 
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Application Domain -ek 


Egy .NET program nem direkt módon processként fut, hanem be van ágyazva egy ún. application domain-be a 
processen belül (egy process több AD-t is tartalmazhat egymástól teljesen elszeparálva). 

Ezzel a megoldással egyrészt eló'segítik a platformfüggetlenséget, hiszen így csak az Application Domaint kell 
portolni egy másik platformra, a benne futó folyamatoknak nem kell ismerniük az operációs rendszert, 
másrészt biztosítja a programok stabilitását, ugyanis ha egy alkalmazás összeomlik egy AD-ben, attól a többi 
még tökéletesen működik majd. 

Amikor elindítunk egy .NET programot, elsőként az alapértelmezett AD (default application domain) jön létre, 
ezután - ha szükséges - a CLR további AD-ket hoz létre. 

A következő program kiírja az aktuális AD nevét: 


using System; 

eláss Program 

{ 

static void Main(string[] args) 

{ 

AppDomain currAD = AppDomain. CurrentDomain; 
Console.WriteLine(currAD.FriendlyName); 

Console. ReadKeyQ; 

} 

} 


Az alkalmazás neve fog megjelenni, hiszen ő az alapértelmezett AD, és egyelőre nincs is több. Hozzunk létre egy 
második AppDomain objektumot: 


using System; 

eláss Program 

{ 

static void Main(string[] args) 

{ 

AppDomain secondAD = AppDomain. CreateDomain("second"); 
Console. WriteLine(secondAD.FriendlyName); 

AppDomain. Unload(secondAD); // megszüntetjük 

Console. ReadKeyQ; 

} 

} 


Szálak 

Elérkeztünk a fejezet eredeti tárgyához, már eleget tudunk ahhoz, hogy megértsük a többszálú alkalmazások 
elvét. Első programunkban lekérjük az adott programrész szálának az azonosítóját: 


using System; 

using System.Threading; 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Console. WriteLine( "Szál-Id: {0}", Thread. CurrentThread.ManagedThreadld); 
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Console. ReadKeyQ; 

} 

} 


A program utasításainak végrehajtása szerint megkülönböztetünk szinkron és aszinkron működést. A fenti 
program szinkron módon működik, az utasításait egymás után hatja végre, ha esetleg egy hosszas algoritmusba 
ütközik, akkor csak akkor lép a következő utasításra, ha azt befejezte, 

Az aszinkron végrehajtás ennek épp az ellentéte, az egyes feladatokat el tudjuk küldeni egy másik szálba, a fő 
szál pedig fut tovább, amíg a mellékszál(ak) vissza nem térnek. 


Aszinkron delegate-ek 

A következőkben delegate-ek segítségével fogunk aszinkron programot írni. Minden egyes delegate 
rendelkezik azzal a képességgel, hogy aszinkron módon hívjuk meg, ezt a Beginlnvoke és Endlnvoke 
metódusokkal fogjuk megtenni. 

Vegyük a következő delegate-et: 


delegate int MyDelegate(int x); 


Ez valójában így néz ki: 


public sealed eláss MyDelegate : System.MulticastDelegate 

{ 

//...metódusok... 

public IAsyncResult BeginInvoke(int x, AsyncCallback eb, object State); 
public int EndInvoke(IAsyncResult result); 

} 


Egyelőre ne foglalkozzunk az ismeretlen dolgokkal, nézzük meg azt, amit ismerünk! A Beginlnvoke-val fogjuk 
meghívni a delegate-et, ennek első paramétere megegyezik a delegate paraméterével (vagy paramétereivel). 
Az Endlnvoke fogja majd az eredményt szolgáltatni, ennek visszatérési értéke megegyezik a delegate-éval. Az 
IAsyncResult objektum, amit a Beginlnvoke visszatérít, segít elérni az eredményt, és az Endlnvoke is ezt kapja 
majd paraméteréül. 

A Beginlnvoke másik két paraméterével most nem foglalkozunk, készítsünk egy egyszerű metódust a delegate- 
hez, és hívjuk meg aszinkron: 


using System; 

using System.Thneading; 

eláss Program 

{ 

public delegate int MyDelegate(int x); 

static int Square(int x) 

{ 

Console. WriteLine( "Szál-ID: {0}", 

Thread.CurrentThread.ManagedThreadld); 
return (x * x); 

} 

static void Main(string[] args) 

{ 

MyDelegate d = Square; 

Console. WriteLine( "Szál-ID: {0}", 
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Thread.CurrentThread.ManagedThreadld); 
IAsyncResult iar = d.BeginInvoke(12, null., null); 
Console. WriteLine( "BlaBla 
int result = d.Endlnvoke(iar); 
Console.WriteLine(result); 

Console. ReadKeyQ; 

} 

} _ 

A kimenet a következő lesz: 


Szál-ID: 1 
BlaBla... 
Szál-ID: 3 
144 


Látható, hogy egy új szál jött létre. Amit fontos megértenünk, hogy a Beginlnvoke azonnal megkezdi a feladata 
végrehajtását, de az eredményhez csak az Endlnvoke hívásakor jutunk hozzá, tehát külső szemlélőként úgy 
látjuk, hogy csak akkor fut le a metódus. A háttérben futó szál üzenete is látszólag csak az eredmény 
kiértékelésénél jelenik meg, az igazság azonban az, hogy a Main üzenete előbb ért a processzorhoz, ezt 
hamarosan látni fogjuk. 

Többszálú program írásánál össze kell tudnunk hangolni a szálak munkavégzését, pl. ha az egyik szálban 
kiszámolt eredményre van szüksége egy másik, később indult szálnak. Ezt szinkronizálásnak nevezzük. 
Szinkronizáljuk az eredeti programunkat, vagyis várjuk meg, amíg a delegate befejezi a futását (természetesen a 
szinkronizálás ennél jóval bonyolultabb, erről a következő fejezetekben olvashatunk): 


using System; 

using System.Threading; 

eláss Program 

{ 

public delegate int MyDelegate(int x); 

static int Square(int x) 

{ 

Console. WriteLine( "Szál-ID: {0}", 

Thread.CurrentThread.ManagedThreadld); 
Thread.Sleep(100) ; 
return (x * x); 

} 

static void Main(string[] args) 

{ 

MyDelegate d = Square; 

Console. WriteLine( "Szál-ID: {0}"., 

Thread.CurrentThread.ManagedThreadld); 

IAsyncResult iar = d.BeginInvoke(12, null, null); 

while (!iar.IsCompleted) 

{ 

Console. WriteLine("BlaBla. .. "); 

} 
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int result = d.Endlnvoke(iar); 


Console.WriteLine(result); 


Console. ReadKeyQ; 

} 

} 


Ezt a feladatot az lAsyncResult interfész IsCompleted tulajdonságával oldottuk meg. A kimenet: 


Szál-ID: 1 

BlaBla... 

BlaBla... 

BlaBla... 

Szál-ID: 3 

BlaBla... 

BlaBla... 

BlaBla... 

BlaBla... 
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Itt már tisztán látszik, hogy az aszinkron metódus futása azonnal elkezdó'dött, igaz, a Main itt is megelőzte. 


A Square metódusban azért használtuk a Sleep metódust, hogy lássunk is valamit, ellenkező esetben túl 
gyorsan lefut ez az egyszerű program. Erősebb számítógépeken nem árt módosítani az alvás idejét akár 1000 
ms-re is. 


Valljuk be, elég macerás mindig meghívogatni az Endlnvoke-ot, így felmerülhet a kérdés, hogy nem lehetne-e 
valahogy automatizálni az egészet. Nos, épp ezt a gondot oldja meg a Beginlnvoke harmadik AsyncCallback 
típusú paramétere. Ez egy delegate, amely egy olyan metódusra mutathat, amelynek visszatérési értéke void, 
valamint egy darab lAsyncResult típusú paraméterrel rendelkezik. Ez a metódus azonnal le fog futni, ha a 
mellékszál elvégezte a feladatát: 


using System; 

using System.Threading; 

using System.Runtime.Remoting.Messaging; // erre a névténre szükség van 

eláss Program 

{ 

public delegate int MyDelegate(int x); 

static int Square(int x) 

{ 

Console. WriteLine( "Szál-ID: {0}"., 

Thread.CurrentThread.ManagedThreadld); 
return (x * x); 

} 

static void AsyncMethodComplete(IAsyncResult iar) 

{ 

Console. WriteLine( "Aszinkron szál kész..."); 

AsyncResult result = (AsyncResult)iar; 

MyDelegate d = (MyDelegate)result.AsyncDelegate; 

Console. WriteLine("Eredmény: {0}" , d.Endlnvoke(iar)); 

} 
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static void Main(string[] args) 

{ 

MyDelegate d = Square; 

Console. WriteLine( "Szál-ID {0}", 

Thread.CurrentThread.ManagedThreadld); 

IAsyncResult iar = d.BeginInvoke(12, 

new AsyncCallback(AsyncMethodComplete)j null); 

Console. WriteLine( "BlaBla 

Console. ReadKeyQ; 

} 

} 


Ha Console.ReadKey nélkül futtatnánk a programot, akkor azt látnánk, hogy nem írja ki az eredményt. Ez azért 
van, mert a „BlaBla" után a program futása megáll, mivel elérte a Main végét, és nincs több utasítás, valamint 
ez gyorsabban történik, minthogy az aszinkron metódus kész lenne. Épp ezért érdemes egy ReadKey vagy egy 
Sleep metódust használni a program végén. 

A kimenet a következő lesz: 


Szál-ID 1 
BlaBla... 

Szál-ID: 3 

Aszinkron szál kész... 
Eredmény: 144 


Egyetlen dolog van hátra, mégpedig a Beginlnvoke utolsó paraméterének megismerése. Ez egy object típusú 
változó, azaz bármilyen objektumot átadhatunk. Ezt a paramétert használjuk, ha valamilyen plusz információt 
akarunk továbbítani. A Beginlnvoke most így néz ki: 


IAsyncResult iar = d.BeginInvoke(12j 

new AsyncCallback(AsyncMethodComplete), "Üzenet a jövőből 


Az üzenetet az IAsyncResult AsyncState tulajdonságával kérdezhetjük le: 


static void AsyncMethodComplete(IAsyncResult iar) 

{ 

Console. WriteLine( "Aszinkron szál kész..."); 

AsyncResult result = (AsyncResult)iar; 

MyDelegate d = (MyDelegate) result.AsyncDelegate; 

Console. WriteLine( "Üzenet: {0}", iar.AsyncState); 
Console. WriteLine("Eredmény: {0}", d.Endlnvoke(iar)); 

} 


Szálak létrehozása 

Ahhoz, hogy másodlagos szálakat hozzunk létre, nem feltétlenül kell delegate-eket használnunk, mi magunk is 
elkészíthetjük őket. Vegyük a következő programot: 


using System; 

using System.Threading; 

eláss Test 
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{ 

public void ThreadInfo() 

{ 

Console. WriteLine( "Szál-név: {0}"., Thread.CurrentThread.Name); 

} 

} 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Thread current = Thread .CurrentThread; 
current.Name = "Current-Thread"; 

Test t = new Test(); 
t.ThreadInfo(); 

Console. ReadKeyQ; 

} 

} 


Elsőként lekértük és elneveztük az elsődleges szálat, hogy később azonosítani tudjuk, mivel alapértelmezetten 
nincs neve. 

A következő programban a Test objektum metódusát egy háttérben futó szálból fogjuk meghívni: 


using System; 

using System.Threading; 

eláss Test 

{ 

public void ThreadInfo() 

{ 

Console. WriteLine( "Szál-név: {0}"j Thread.CurrentThread.Name); 

} 

} 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Test t = new Test(); 

Thread backgroundThread = new Thread( 
new ThreadStart(t.Threadlnfo)); 
backgroundThread.Name = "Background-Thread"; 
backgroundThread.Start(); 

} 

} 


A Thread konstruktorában szereplő ThreadStart delegate-nek kell megadnunk azt a metódust, amelyet a 
másodlagos szál majd futtat. A programot érdemes Console.ReadKey nélkül futtatni, mivel azon fennakadna a 
futás. így is csak egy villanást lehet látni belőle, parancssorból indítva látványosabb lehet. 

Ez eddig szép és jó, de mi van akkor, ha a meghívott metódusnak paraméterei is vannak? Ilyenkor a 
ThreadStart parametrizált változatát használhatjuk, ami igen eredeti módon a ParameterizedThreadStart 
névre hallgat. A ThreadStart-hoz hasonlóan ez is egy delegate, szintén void visszatérési típusa lesz, a 
paramétere pedig object típusú lehet: 
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using System; 

using System.Threading; 

eláss Test 

{ 

public void ThreadInfo(object paraméter) 

{ 

Console.WriteLine( "Szál-név: {0}"j Thread.CurrentThread.Name); 

if (paraméter is string) 

{ 

Console.WriteLine("Paraméter: {0}", paraméter); 

} 

} 

} 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Test t = new Test(); 

Thread backgroundThread = new Thread(new 

ParameterizedThreadStart (t.ThreadInfo)); 

backgroundThread.Name = "Background-Thread"; 
backgroundThread.Start( "Hello" ); 

Console. ReadKey(); 

} 

} 


Nyílván a metódusban nem árt ellenőrizni a paraméter típusát, mielőtt bármit csinálunk vele. 


Foreground és background szálak 

A .NET két különböző száltípust különböztet meg: amelyek előtérben és amelyek a háttérben futnak. A kettő 
közti különbség a következő: a CLR addig nem állítja le az alkalmazást, amíg egy előtérbeli szál is dolgozik, 
ugyanez a háttérbeli szálakra nem vonatkozik (az aszinkron delegate esetében is ezért kellett a program végére 
a „lassítás"). 

Logikus (lenne) a feltételezés, hogy az elsődleges és másodlagos szálak fogalma megegyezik jelen fejezetünk 
tárgyaival. Az igazság viszont az, hogy ez az állítás nem állja meg a helyét, ugyanis alapértelmezés szerint 
minden szál (a létrehozás módjától és idejétől függetlenül) előtérben fut. Természetesen van arra is lehetőség, 
hogy a háttérbe küldjük őket: 


using System; 

using System.Threading; 

eláss Test 

{ 

public void ThreadInfo() 

{ 

Thread. Sleep(5000); 

Console. WriteLine( "Szál-név: {0}" , Thread.CurrentThread.Name); 

} 

} 

eláss Program 

{ 

static void Main(string[] args) 
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{ 

Test t = new Test(); 

Thread backgroundThread = new Thread( 
new ThreadStart(t.Threadlnfo)); 
backgroundThread.IsBackground = true; 
backgroundThread.Name = "Background-Thread"; 
backgroundThread.Start(); 

} 

} 


Ez a program semmit nem fog kiírni, és pont ezt is vártuk tőle, mivel beállítottuk az IsBackground 
tulajdonságot, ezért az általunk készített szál „valódi" háttérben futó szál lett, vagyis a főszálnak nem kell 
megvárnia, hogy végezzen a dolgával. 


SZINKRONIZÁCIÓ 


A szálak szinkronizációjának egy primitívebb formáját már láttuk a delegate-ek esetében, most egy kicsit 
komolyabban közelítünk a témához. 

Négyféleképpen szinkronizálhatjuk a szálainkat, ezek közül az első a blokkolás. Ennek már ismerjük egy módját, 

ez a Thread.Sleep metódus: 


using System; 

using System.Threading; 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Console.WriteLine( "Start... 
Thread. Sleep(2000); 
Console.WriteLine("Stop. .. "); 

Console. ReadKeyQ; 

} 

} 


Amikor egy szálat leblokkolunk, az azonnal „elereszti" a processzort, és addig inaktív marad, amíg a blokkolás 
feltételének a környezet eleget nem tesz, vagy a folyamat valamilyen módon megszakad. 

A Jóin metódus addig várakoztatja a hívó szálat, amíg az a szál, amin meghívták, nem végezte el a feladatát: 


using System; 

using System.Threading; 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Thread t = new Thread(delegate() { Thread. Sleep(2000); }); 

t .Start(); 

t.DoinQ; 

Console. WriteLine( "Vége") ; 

Console. ReadKeyQ; 

} 

} 
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A Join-nak megadhatunk egy „timeout" paramétert (ezredmásodpercben), amely idő lejárta után - ha a szál 
nem végzett feladatával - hamis értékkel tér vissza. A következő példa (ezúttal lambda kifejezéssel) ezt mutatja 
meg: 


using System; 

using System.Threading; 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Thread t = new Thread(() => Thread.Sleep(2000)); 
t .Start(); 

if (t.loin(1000) == false) 

{ 

Console.WriteLine("Az idő lejárt..."); 
t.Abort(); // megszakítjuk a szál futását 

} 

Console. ReadKeyQ; 

} 

} 


A következő szinkronizációs módszer a lezárás (locking). Ez azt jelenti, hogy erőforrásokhoz, illetve a program 
bizonyos részeihez egyszerre csak egy szálnak engedünk hozzáférést. Ha egy szál hozzá akar férni az adott 
dologhoz, amelyet egy másik szál már használ, akkor automatikusan blokkolódik, és várólistára kerül, ahonnan 
érkezési sorrendben lehet hozzájutni az erőforráshoz (ha az előző szál már végzett). Nézzük a következő példát: 


using System; 

using System.Threading; 


eláss Test 

{ 

static int x = 10; 
static int y = 20; 

static public void Divide() 

{ 

if (Test.x != 0) 

{ 

Thread. Sleep(2); 

Console. WriteLine(Test.y / Test.x); 

Test.x = 0; 

} 

} 

} 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Thread ti = new Thread(new ThreadStart(Test.Divide)); 
Thread t2 = new Thread(new ThreadStart(Test.Divide)); 
tl.Start(); 
t2.Start(); 

} 
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Tegyük fel, hogy megérkezik egy szál, eljut odáig, hogy kiírja az eredményt, és épp ekkor érkezik egy másik szál 
is! Megvizsgálja a feltételt, rendben találja és továbblép. Ebben a pillanatban azonban az elsőként érkezett szál 
lenullázza a változót, és amikor a második szál osztani akar, akkor kap egy szép kis kivételt. A Divide metódus 
feltételében nem véletlenül van ott a Sleep, ezzel teszünk róla, hogy tényleg legyen kivétel. Mivel ez egy 
egyszerű program, muszáj lelassítani egy kicsit az első szálat (érdemes többször lefuttatni, nem biztos, hogy 
azonnal kivételt kapunk). 

A műveletet lezárhatjuk a következő módon: 


static object locken = new object(); 

static public void Divide() 

{ 

lock (locken) 

{ 

if (Test.x != 0) 

{ 

Thread.Sleep(2); 

Console.WniteLine(Test.y / Test.x); 
Test.x = 0; 

} 

} 

} 


A lock kijelöl egy blokkot, amelyhez egyszerre csak egy szál fér hozzá. Ahhoz azonban, hogy ezt megtehessük, ki 
kell jelölnünk egy ún. tóként, amelyet lezárhat. A tokennek minden esetben referenciatípusnak kell lennie. 

A lock-hoz hasonlóan működik a Mutex is, a legnagyobb különbség az a kettő közt, hogy utóbbi processz 
szinten zárol, azaz a számítógépen futó összes folyamat elől elzárja a használat lehetőségét. Az 
erőforrás/metódus/stb. használata előtt meg kell hívnunk a WaitOne metódust, a használat után pedig el kell 
engednünk az erőforrást a ReleaseMutex metódussal (ha ezt nem tesszük meg a kódból, akkor az alkalmazás 
futásának végén a CLR automatikusan megteszi helyettünk). A következő példában létrehozunk több szálat, és 
versenyeztetjük őket egy metódus használatáért. Elsőként készítsük el az osztályt, amely tárolja az „erőforrást" 
és a Mutex objektumot: 


eláss Test 

{ 

priváté Mutex mutex = new Mutex(); 

public void ResourceMetod() 

{ 

mutex.WaitOne(); 

Console.WriteLine( "{0} használja az erőforrást... 
Thread.CurrentThread.Name); 

Thread. Sleep(1000); 

mutex.ReleaseMutex(); 

Console.WriteLine( "{0} elengedi az erőforrást... 
Thread.CurrentThread.Name); 

} 

} 


Most pedig jöjjön a főprogram: 


eláss Program 

{ 

static Test t = new Test(); 
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static public void ResourceUserMethod() 

{ 

fór (int i = 0; i < 10; ++i) 

{ 

t.ResourceMetod(); 

} 

} 

static void Main(string[] args) 

{ 

List<Thread> threadList = new List<Thread>( ); 

fór (int i = 0; i < 10; ++i) 

{ 

threadList.Add( 

new Thread(new ThreadStart(Program. ResourceUserMethod)) 

{ 

Name = "Thread" + i.ToString() 

}); 

} 

threadList.ForEach((thread) => thread.Start()); 

} 

} 


A Semaphore hasonlít a lock-ra és a Mutex-re, azzal a különbséggel, hogy megadhatunk egy számot, amely 
meghatározza, hogy egy erőforráshoz maximum hány szál férhet hozzá egy időben. A következő program az 
előző átirata, egy időben maximum három szál férhet hozzá a metódushoz: 


eláss Test 

{ 

priváté Semaphore semaphore = new Semaphore(3, 3); 

public void ResourceMetod() 

{ 

semaphore.WaitOne(); 

Console.WriteLine( "{0} használja az erőforrást ... ", 
Thread. CurrentThread.Name); 

Thread.Sleep(1000); 

semaphore.Release(); 

Console.WriteLine( "{0} elengedi az erőforrást... ", 
Thread. CurrentThread.Name); 

} 

} 


A főprogram pedig ugyanaz lesz. 


ThreadPool 

Képzeljük el a következő szituációt: egy kliens-szerver alkalmazást készítünk, a szerver a főszálban figyeli a 
bejövő kapcsolatokat, és ha kliens érkezik, akkor készít neki egy szálat, majd a háttérben kiszolgálja. Tegyük 
még hozzá azt is, hogy a kliensek viszonylag rövid ideig tartják a kapcsolatot a szerverrel, viszont sokan vannak! 
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Ha úgy készítjük el a programot, hogy a bejövő kapcsolatoknak mindig új szálat készítünk, akkor nagyon 
gyorsan teljesítményproblémákba fogunk ütközni: 

• Egy objektum létrehozása költséges. 

• Ha már nem használjuk, akkor a memóriában marad, amíg el nem takarítja a GC. 

• Mivel sok bejövő kapcsolatunk van, ezért hamarabb lesz tele a memória szeméttel, vagyis gyakrabban 
fut majd a GC. 

A probléma gyökere az egyes pont, vagyis az, hogy minden egyes kapcsolatnak új szálat készítünk, majd 
eldobjuk azt. Sokkal hatékonyabbak lehetnénk, ha megpróbálnánk valahogy újrahasznosítani a szálakat. Ezt a 
módszert thread-pooling-nak nevezzük, és szerencsénk van, mivel a .NET beépített megoldással rendelkezik 
(ugyanakkor, ha igazán hatékonyak akarunk lenni, írhatunk saját, az adott követelményeknek legjobban 
megfelelő ThreadPool osztályt is). 

Egy későbbi fejezetben elkészítünk majd egy, a fenti felvázolt helyzethez hasonló programot, most „csak" egy 
egyszerű példán keresztül fogjuk megvizsgálni ezt a technikát. Nézzük meg a következő programot: 


using System; 

using System.Threading; 

eláss Program 

{ 

static public void Do(object inObj) 

{ 

Console.WriteLine( "A következő adatot használjuk: {0}"., 
(int) inObj); 

Thread.Sleep(500); 

} 

static void Main(string[] args) 

{ 

ThreadPool. SetMaxThreads(5, 0); 

fór (int i = 0; i < 20; ++i) 

{ 

ThreadPool .QueueUserWorkItem( 

new WaitCallback(Program.Do) j 

i); 

} 

Console. ReadKeyQ; 

} 

} 


Ami elsősorban feltűnhet, az az, hogy a ThreadPool egy statikus osztály,vagyis nem tudjuk példányosítani, 
ehelyett a metódusait használhatjuk. A SetMaxThread metódus a maximálisan memóriában tartott szálak 
számát állítja be, az első paraméter a „rendes", a második az aszinkron szálak számát jelzi (utóbbira most nincs 
szükség, ezért kapott nulla értéket). 

A QueuellserWorkltem metódus lesz a ThreadPool lelke, itt indítjuk útjára az egyes szálakat. Ha egy „feladat" 
bekerül a listára, de nincs az adott pillanatban szabad szál, akkor addig vár, amíg nem kap egyet. A metódus 
első paramétere egy delegate, amely olyan metódusra mutathat, amelynek visszatérési értéke nincs (void), és 
egyetlen object típusú paraméterrel rendelkezik. Ezt a paramétert adjuk meg a második paraméterben. 

Fontos tudni, hogy a ThreadPool osztály csakis background szálakat indít, vagyis a program nem fog várni, amíg 
minden szál végez, hanem kilép. Ennek megakadályozására tettünk a program végére egy Console.ReadKey 
parancsot, így látni is fogjuk, hogy mi történik éppen (erre pl. a fent említett kliens-szerver példában nincs 
szükség, mivel a szerver a főszálban végtelen ciklusban várja a bejövő kapcsolatokat). 
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PÁRHUZAMOS PROGRAMOZÁS - TASK PARALLEL LlBRARY 


Ma már a legtöbb számítógép több processzormaggal rendelkezik, amelyek fizikailag is lehetővé teszik több szál 
párhuzamos futását. Ahhoz, hogy az ebben rejlő lehetőségeket kihasználjuk, a múltban alacsony szinten, 
közvetlenül a szálakkal kellett dolgoznunk. A .NET Framework 4 (és a C# 4.0) olyan új osztályokat és 
keretrendszert ad a kezünkbe, amelyekkel ezeket a feladatokat leegyszerűsíthetjük. 


Többszálúság vs. Párhuzamosság 

Amikor többszálú programokat készítünk, alapvetően nem törődünk a hardver lehetőségeivel, létrehozunk 
szálakat, amelyek versengnek a processzoridőért. Ilyenkor értelemszerűen nem fogunk különösebb 
teljesítménynövekedést kapni, hiszen minden művelet ugyanannyi ideig tart, nem tudjuk őket közvetlenül 
szétosztani az - esetleges - több processzor között. Ezt a módszert pl. olyankor használjuk, amikor nem 
akarjuk, hogy a háttérben futó szálak megzavarják a „főszál" kezelhetőségét (pl. ha egy böngészőben több 
oldalt is megnyitunk, nem akarjuk megvárni, amíg mindegyik letöltődik), vagy egyszerre több „kérést" kell 
kezelnünk (pl. egy kliens-szerver kapcsolat). A párhuzamos programozás ugyanezt nyújtja, de képes a 
processzorok számának függvényében szétosztani a munkát a CPU-k között, ezzel pedig 
teljesítménynövekedést ér el. Ennek a módszernek a nagy hátránya, hogy olyan algoritmust kell találjunk, 
amely minden helyzetben a lehető leghatékonyabban tudja elosztani a munkát, anékül, hogy bármely 
processzor üresjáratban állna. 


Teljesítmény 

Nagyon könnyen azt gondolhatjuk, hogy a processzorok számának növelésével egyenes arányban nő a 
teljesítmény, magyarul két processzor kétszer gyorsabb, mint egy. Ez az állítás nem teljesen igaz (ezt később a 
saját szemünkkel is látni fogjuk), ezt pedig Gene Amdahl bizonyította (Amdahl's Law), miszerint: 

Egy párhuzamos program maximum olyan gyors lehet, mint a leghosszabb szekvenciális (tovább már nem 
párhuzamosítható) részegysége. 

Vegyünk például egy programot, amely 10 órán keresztül fut nem párhuzamosan. Ennek a programnak 9 órányi 
„része" párhuzamosítható, míg a maradék egy óra nem. Ha ezt a 9 órát párhuzamosítjuk, akkor a tétel alapján a 
programnak így is minimum egy órás futásideje lesz. 

Amdahl a következő képletet találta ki: 


1 

(1 -P) + P/N 

Ahol P a program azon része, amely párhuzamosítható, (1 - P) az, amelyik nem, N pedig a processzorok száma. 
Nézzük meg, hogy mekkora a maximum teljesítmény, amit a fenti esetből ki tudunk préselni! P ekkor 0,9 lesz (9 
óra = 90% = 0,9), és a képlet (két processzort használva): 

1 

(1 - 0,9) + 0,9/2 

Könnyen kiszámolható, hogy az eredmény 1/0,55 (1,81) lesz, vagyis 81% -os teljesítménynövekedést érhetünk 
el két processzor bevezetésével. Vegyük észre, hogy a processzorok számának növelésével P/N a nullához tart, 
vagyis kimondhatjuk, hogy minden párhuzamosítható feladat maximum 1/(1 - P) nagyságrendű 
teljesítménynövekedést eredményezhet (feltételezve, hogy mindig annyi processzor áll rendelkezésünkre, hogy 
P/N a lehető legközelebb legyen nullához: ez nem feltétlenül jelent nagyon sokat, a példa esetében 5 
processzor már 550%-os növekedést jelent, innen pedig egyre lassabban nő az eredmény, mivel ekkor P/N 
értéke már 0,18, hat processzornál 0,15 és így tovább). Tehát a fenti konkrét esetben a maximális teljesítmény 
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a hagyományos futásidő tízszerese lehet (1 / (1 - 0,9), vagyis pontosan az az egy óra, amelyet a nem 
párhuzamosítható programrész használ fel! 


PÁRHUZAMOS CIKLUSOK 


A TPL tartalmazza a fór és foreach ciklusok párhuzamosított változatát. Nézzünk meg egyszerű példát, 
hasonlítsuk össze a „sima" fór és a párhuzamos fór teljesítményét! Készítsünk egy tömböt, töltsük fel 
számokkal, és írjuk ki a tartalmát! Nem valami okos példa, de arra elég, hogy lássuk a párhuzamos változatok 
szintaxisát. 


using System; 
using System.Diagnostics; 
using System.Threading.Tasks; 
using System.Linq; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

int [] array = Enumerable.Range(0j 10000) .ToArray<int>(); 

Stopwatch sw = new Stopwatch(); 

long resultl = 0; 
long result2 = 0; 

sw.Start(); 

Parallel. For( 

0j //honnan 

array.Lengthj //meddig 

(i) => Console.WriteLine(array[i])); //ciklustörzs 
sw.Stop(); 

resultl = sw.ElapsedMilliseconds; 

sw.Reset(); 
sw.Start(); 

fór (int i = 0; i < array.Length; ++i) 

{ 

Console.WriteLine(array[i]); 

} 

sw.Stop(); 

result2 = sw.ElapsedMilliseconds; 

Console.WriteLine("Az első ciklus által felhasznált idő: {0} ms", 
resultl); 

Console.WriteLine("A második ciklus által felhasznált idő: {0} ms", 
result2); 

Console .ReadKey(); 

} 

} 

} 
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A Parallel.Fór ebben a legegyszerűbb változatában három paramétert vár, akárcsak a nem párhuzamos társa: a 
ciklusváltozó kiindulási értékét, a maximális értéket (amely már nem számít bele az iterációkba), illetve a 
ciklustörzset. A ciklusváltozó int vagy long típusú lehet, és minden esetben eggyel lép eló're. 

Az Enumerable.Rangé a paramétereiként megadott intervallumban generál számokat, ezen meghíva a ToArray 
függvényt visszakapjuk ennek a sorozatnak a tömbalakját. 

A Stopwatch osztályt használjuk idó'mérésre? a Start és Stop metódusával elindítjuk, illetve megállítjuk az órát, 
a Rését pedig alaphelyzetbe rakja. 

Ha megnézzük a program futása után az eredményeket, akkor azt látjuk, hogy a kétféle ciklus nagyjából 
ugyanannyi idő alatt írta ki a 10000 számot. Azt is vegyük észre, hogy míg a rendes változat sorrendben veszi 
elő' a számokat a tömbbó'l, addig a párhuzamos meglehetős összevisszaságban! Ennek oka, hogy utóbbi esetben 
a párhuzamos végrehajtás csoportokba rendezi az elemeket (particionálja) és az egyes csoportokat küldi 
feldolgozásra. Ezek aztán nem sorrendben érkeznek a processzorhoz, így a kimenet nem rendezett. 

Nézzünk egy összetettebb példát: adjuk össze az első egymillió számot! A forráskód a következő lesz: 


using System; 
using System.Diagnostics; 
using System.Thneading.Tasks; 
using System.Linq; 

using System.Collections.Concunnent; 
using System.Thneading; 

namespace TestApp 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

int[] array = Enumerable. Range(l, 1000000).ToArray<int>(); 

Stopwatch sw = new Stopwatch(); 

long sum = 0; 

sw.Start(); 

fór (int i = 0; i < array.Length; ++i) 

{ 

sum += array[i]; 

} 

sw.Stop(); 

Console.WriteLine("Az eredmény: {0}", sum); 
Console.WriteLine("A ciklus által felhasznált idő: {0} ms"., 
sw.ElapsedMilliseconds); 

sum = 0; 
sw.Reset(); 
sw.Start(); 

Parallel. For(0j 
array.Length, 

(i) => sum += array[i]); 

sw.Stop(); 

Console.WriteLine("Az eredmény: {0}", sum); 
Console.WriteLine("A ciklus által felhasznált idő: {0} ms"., 
sw.ElapsedMilliseconds); 

Console .ReadKey(); 
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} 


} 


} 


Ha elindítjuk a programot, két nagyon érdekes dolgot tapasztalunk: a párhuzamos változat jelentősen lassabb 
(akár négy-ötször is), illetve rossz eredményt is ad vissza. 

Elsősorban kezeljük az utóbbi problémát: a Parallel.Fór ha mást nem adtunk meg, automatikusan int tipusú 
ciklusváltozót használ, amelyben a várt eredmény nem fér el. írjuk át long típusra: 


Parallel. For(0, 
array.Length, 

(long i) => sum += array[i]); 


Ezután is fennáll azonban, hogy sok esetben rossz az eredmény (nem árt néhányszor futtatni). Miért van ez így? 
A TPL ugyan egyszerűsíti a dolgunkat, de nem lehet ész nélkül használni. Ebben az esetben az alapprobléma, 
hogy egy cikluson kívüli változót használunk, ráadásul olyan művelettel, amely nem szálbiztos. 

A += operátor itt sum = sum + array[i] alakban értékelődik ki. Képzeljük el, hogy megérkezik az egyik szál, 
elkezd számolni, ebben a pillanatban pedig egy újabb szál bukkan fel! Az első már kisajátította magának a sum 
változót, a második nem jut hozzá, az adott művelet egyszerűen kimarad. így már nem csoda, hogy a 
végeredmény nem megfelelő, 
írjuk át ismét a párhuzamos ciklust: 


Parallel. For(0, 
array.Length, 

0 => 0 , 

(long i, ParallelLoopState loop, long totál) => 

{ 

totál += array[i]; return totál; 

(x) => Interlocked.Add(ref sum, x)); 


A paraméterek sorban: a ciklusváltozó kiindulási értéke, a maximális érték, utána a programrész, amellyel az 
egyes szálaknak adhatunk információt. Az utolsó két paraméter a lényeg: az első maga is kap három 
paramétert, ezek a ciklusváltozó, egy objektum, amelynek segítségével idő előtt leállíthatjuk a ciklus futását, 
illetve egy változó, amelyet továbbadhatunk a további iterációknak. A ciklustörzs ennek fényében egyszerű: a 
„helyi" változónkat használjuk az összeadáshoz. 

Végül a Fór utolsó paramétere jön, amely a szálbiztos műveleteket segíti: az Interlocked osztállyal elemi 
műveleteket végezhetünk (ebben az esetben összeadást). Ez a függvény nem fut le minden egyes iterációban, 
helyette az egyes szálak működése végén hívja meg csak a rendszer, ezáltal jelentős mennyiségű teljesítményt 
nyerhetünk. 

Ha újra futtatjuk a programunk, most már minden esetben helyes végeredményt kapunk, viszont a sebesség 
nem változott. 

Ezzel el is érkeztünk a fejezet lényegéhez: a párhuzamos végrehajtás meglehetősen nagy odafigyelést és 
speciális körülményeket igényel. Amennyiben a ciklustörzs rövid (értsd: kevés vagy olcsó művelet) magának a 
párhuzamosságnak a beüzemelése megöli a teljesítményt, gyakorlatilag több erőforrás szükséges hozzá mint a 
műveletek végrehajtásához. 

Ugyanígy a lehetséges műveletek is behatároltak, ahogy láttuk, nem biztos, hogy jó ötlet külső változókat, 
objektumokat használni (viszont tömbök esetén ha az egyes elemekkel dolgozunk amíg nem módosítunk 
többször egy elemet, addig szálbiztos a program). Nem árt azt is tudni, hogy érdemes olyan műveletek et 
használni, ahol az egyes részeredmények nem függenek egymástól (persze vannak módszerek a kevésbé 
egyértelmű esetek kezelésére is). 

Nem kell azonban elkeseredni, a TPL ettől függetlenül is rendkívül hasznos. Nézzünk meg egy olyan példát, ahol 
tényleges előnyhöz jutunk használatával! A következő programunkban mátrixokat szorzunk össze, ez egy 
kellően komplex műveletsorozatot igényel. Lássuk, hogy teljesít a párhuzamos ciklus. Készítsünk először egy 
függvényt, amellyel tetszőleges méretű mátrixot generálhatunk: 
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static public double[,] GenerateMatrix(int size) 

{ 

double[j] mátrix = new double[size, size]; 

Random r = new Random(); 

fór (int i = 0; i < size; ++i) 

{ 

fór (int j = 0; j < size; ++j) 

{ 

matrix[i, j] = r.Next(1000, 100000); 

} 

} 

return mátrix; 

} 


Most jöjjön a szorzást végző programrész a „tesztcsomaggal": 


static void Main(string[] args) 

{ 

int size = 1000; 

double[,] a = GenerateMatrix(size); 
double[,] b = GenerateMatrix(size); 
double[,] c = new doublefsize, size]; 

Stopwatch sw = new Stopwatch(); 

sw.Start(); 

fór (int i = 0; i < size; ++i) 

{ 

fór (int j = 0; j < size; ++j) 

{ 

double v = 0; 

fór (int k = 0; k < size; ++k) 

{ 

v += a[i, k] * b[kj j]; 

} 

c[i, j] = v; 

} 

} 

sw.Stop(); 

Console.WriteLine("A ciklus által felhasznált idő: {0} ms", 
sw.ElapsedMilliseconds); 

c = new double[size, size]; 
sw.Reset(); 

sw.Start(); 

Parallel. For(0, size^ (i) => 

{ 

fór (int j = 0; j < size; ++j) 

{ 

double v = 0; 

fór (int k = 0; k < size; ++k) 

{ 
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V += a[ij k] * b[k, j]j 

} 


c[ij j] = VJ 

} 

}); 


sw.Stop()j 


Console .WriteLine( "A ciklus által felhasznált idő: {0} ms", 
sw.ElapsedMilliseconds); 


Console .ReadKey()j 


A 100x100-as mátrixok összeszorzására a tesztgépen (AMD 255 X2, két mag) a „hagyományos" ciklusnak 14 
másodpercre volt szüksége, a párhuzamos 10 alatt végzett. lOOOxlOOO-es mátrixokkal hasonló az előny: 162 
másodperc 108 ellen. Látható, hogy egy „elavult" processzor felett is közel 50% plusz teljesítményt lehet 
kifacsarni a rendszerből. 

A Parallel.For-nál jóval rugalmasabb a Paralell.ForEach. Amíg előbbinél csak egy számsorozaton iteráltunk át és 
külső forrásból szedtük elő az adatokat, megküzdve a szálbiztosság rémével, addig utóbbi közvetlenül egy 
gyűjtemény elemein megy végig. 

írjunk egy programot, amellyel egy könyvtár fájljait tudjuk feldolgozni: 


using Systemj 

using System.Threading.Tasks; 
using System.IOj 

namespace TestApp 

{ 

eláss Program 

{ 

static public void Main(string[ ] args) 

{ 

Directorylnfo di = new DirectoryInfo("D:\\")j 

Parallel. ForEach(di.GetFiles()j (fiié) => 

{ 

Console.WriteLine(file.FullName); 

}); 

Console .ReadKey()j 

} 

} 

} 


A For-hoz hasonló a szintaxis, de ebben az esetben a „ciklustörzs" számára az aktuális elemet adjuk át. 


Parallel.Invoke 

Ciklusokkal egy adott feladatot hajthatunk végre többször. Ha viszont több különböző - akár egymástól 
független - akciót szeretnénk elvégezni, akkor más eszközt kell választanunk. A Parallel.Invoke épp' ennek a 
feltételnek tesz eleget: paramétereként tetszőleges számú tevékenységet adhatunk meg, amelyeket aztán 
párhuzamosan hajt végre: 
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using System; 

using System.Threading.Tasks; 
using System.Net; 

namespace TestApp 

{ 

eláss Program 

{ 

static public void Main(string[ ] args) 

{ 

Parallel. Invoke( 

() => Console.WriteLine("Task 1"), 
() => Console.WriteLine("Task 2"), 
() => Console.WriteLine("Task 3") 
); 

Console .ReadKey(); 

} 

} 

} 


Az Invoke Action delegate-ek paramétertömbjét várja paraméterként, ezeknek nem lehet bemenő paramétere. 
A fenti program egyszerűen kiírja a három „mondatot", csináljunk valami bonyolultabbat. Például egy hosszabb 
szövegből keressük meg a leghosszabb szót, és hogy összesen hány szó szerepel az írásban! 


using System; 

using System.Threading.Tasks; 
using System.Net; 
using System.Linq; 

namespace TestApp 

{ 

eláss Program 

{ 

static public void Main(string[ ] args) 

{ 

WebClient wc = new WebClient(); 

string[] s = wc.DownloadString( 

"http://www.gutenberg.org/cache/epub/103/pgl03 .txt") 

.Split( 

new char[] { ' '\u000A', '/' }, 

StringSplitOptions .RemoveEmptyEntries 

); 

Parallel. Invoke( 

() => Console .WriteLine( 

s.OrderByDescending((item) => item.Length).First()), 

() => Console. WriteLine(s.Length) 

); 

Console .ReadKey(); 

} 

} 

} 


Ha futtatjuk a programot, akkor észrevehetjük, hogy nem biztos, hogy az általunk megadott sorrendben futnak 
le az egyes műveletek. Illetve vegyük észre azt is, hogy ugyanazt az erőforrást használja a két Action objektum, 
de mivel nem végeznek rajta módosítást, ezért a műveletek szálbiztosak. 
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Task 


A TPL egyik alapköve a Task osztály. Ne keverjük össze azonban ó't a szálakkal! Egy Task objektum egy komplett 
párhuzamos feladatot reprezentál, míg egy szál csak a munkafolyamat része. Ugyanakkor ennek az osztálynak a 
kezelése eléggé hasonlít a szálakéhoz. Nézzünk is egy egyszerű példát: 


using System; 

using System.Threading.Tasks; 


namespace TestApp 

{ 

eláss Program 

{ 

static public void Main(string[ ] args) 

{ 

Task taskl = Task. Factory.StartNew( 

() => Console.WriteLine("Én egy Task vagyok!") 

); 


Task task2 = Task. Factory.StartNew( 

() => Console.WriteLine("Én is egy Task vagyok!") 

); 


} 


} 


task2.Wait(); 
Console .ReadKey(); 


A Task.Factory.StartNew egy új Task objektumot ad vissza, amelyet egyúttal el is indít. A Wait metódus 
megvárja, amíg a hozzá tartozó objektum befejezi a futását. Fia nem hívtuk volna meg, a program indításakor 
semmit nem látnánk, hiszen a Console.ReadKey blokkolja a főszálat. Egy billentyűleütés után megjelenne a két 
mondat, de ugye csak egy villanásnyi időre. 

Ugyanez a helyzet, ha „kézzel" gyártunk egy Task objektumot: 


using System; 

using System.Threading.Tasks; 

namespace TestApp 

{ 

eláss Program 

{ 

static public void Main(string[ ] args) 

{ 

Task task = new Task( 

() => Console. WriteLine("Én egy Task vagyok!") 

); 

task.Start(); 

task.Wait(); 

Console .ReadKey(); 

} 

} 

} 


Egy Task objektum eredményt is adhat vissza a következőképpen: 
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using System; 

using System.Threading.Tasks; 

namespace TestApp 

{ 

eláss Program 

{ 

static public void Main(string[ ] args) 

{ 

Task<int> task = new Task<int>( 

() => { return 10; } 

); 

task.Start(); 

Console.WriteLine(task.Result); // 10 
Console .ReadKey(); 

} 

} 

} 


A Task paraméteresített változatán megjelenik a Result tulajdonság. Ilyenkor a paraméter típusa lesz a 
visszatérési érték típusa. Hasonlóképpen járunk el a Task.Factory.StartNew esetében is. Egy Taskhoz 
rendelhetünk paramétert is: 


using System; 

using System.Threading.Tasks; 

namespace TestApp 

{ 

eláss Program 

{ 

static public void Main(string[ ] args) 

{ 

string[] array = new string[] 

{ 

"Én egy Task vagyok!", 

"Én is egy Task vagyok!", 

"Én nem vagyok egy Task!" 

}J 

foreach (string item in array) 

{ 

Task task = new Task( 

(obj) => Console. WriteLine(obj), 
item); 

task.Start(); 

} 

Console .ReadKey(); 

} 

} 

} 


A paramétert a Taskon belül object típusúnak látjuk, ha szükséges, el kell végezni a megfelelő konverziót. 
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Async/Await 


Amikor egy aszinkron programrészt hívunk meg, meglehetősen hosszú forráskódot kell írnunk. El kell indítani a 
folyamatot, majd ha végzett, egy másik függvénynek át kell adnunk az eredményt, ahonnan ki tudja, hová 
utazik majd tovább. A C# 5.0 és a .NET 4.5 bevezeti az async/await kulcsszavakat, amelyek segítségével 
igencsak leegyszerűsödik ez a folyamat. Az alábbi forráskódok lefordításához Visual Stúdió 2011-re van szükség! 
Nézzük meg, hogy működik ez az új konstrukció: 


using System; 

using System.Threading; 

using System.Threading.Tasks; 

namespace AsyncDemo 

{ 

eláss Program 

{ 

static async void DoOperations() 

{ 

var result = await Task<string>.Factory.StartNew( 
() => ReallyLongOperationQ 
)J 

Console.WriteLine("Az eredmény: {0}", result); 

} 

static string ReallyLongOperation() 

{ 

Thread.Sleep(2000); 
return "Siker"; 

} 

static void Main(string[] args) 

{ 

Console.WriteLine("A művelet előtt..."); 
DoOperations(); 

Console.WriteLine("A művelet után..."); 

Console .ReadKey(); 

} 

} 

} 


Ha futtatjuk a programot, akkor látni fogjuk, hogy az „előtt" és „után" üzenetek jelennek meg először, és csak 
utánuk az eredmény, ami arra utal, hogy a ReallyLongOperation függvény aszinkron módon futott le. Hogyan 
értük ezt el? A metódus szignatúrája elé helyezett async szó azt jelzi a fordítónak, hogy a blokkjában valahol 
használni szeretnénk az await utasítást. Amikor ahhoz a bizonyos helyhez ér a program futása, az történik, hogy 
abban a pillanatban a metódus futása megszakad, és háttérbe vonul, amíg az adott művelet véget nem ér. 
Azután felébred és befejezi a feladatát. 

Az async kulcsszót csakis olyan metódusok/függvények esetében használhatjuk, ahol a visszatérési érték típusa 
void, Task vagy Task<T> (néhány kivétellel, például a Main-en nem lehet). Az async megléte nem kötelez 
minket az await használatára, ez fordítva viszont nem igaz. 

Az await utasítást használhatjuk minden olyan függvényen, amelynek visszatérési típusa Task vagy Task<T>, 
illetve ha megvalósítja a függvényt tartalmazó osztály a GetAwaiter metódust. A .NET 4.5 beépítve tartalmaz 
olyan műveleteket, amelyek használhatóak ezzel az utasítással, például a különböző Stream osztályok több 
metódusa is ilyen. Jellemzően Async utótagot kapnak, illetve az IntelliSense a függvény/metódus 
paraméterlistája mellett megjeleníti az awaitable szót is. 
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Reflection 


A „reflection" fogalmát olyan programozási technikára alkalmazzuk, ahol a program (futás közben) képes 
megváltoztatni saját struktúráját és viselkedését. Az erre a paradigmára épülő programozást reflektív 
programozásnak nevezzük. 

Ebben a fejezetben csak egy rövid példát találhat a kedves olvasó, a Reflection témaköre óriási, és a 
mindennapi programozási feladatok végzése közben viszonylag ritkán szorulunk rá (ugyanakkor bizonyos 
esetekben nagy hatékonysággal járhat a használata). Vegyük a következő példát: 


using System; 

eláss Test 

{ 

} 

eláss Program 

{ 

static public void Main(string[ ] args) 

{ 

Test t = new Test(); 

Type type = t.GetType(); 

Console. WriteLine(type); // Test 

Console. ReadKeyQ; 

} 

} 


Futásidőben lekértük az objektum típusát (a GetType metódust minden osztály örökli az object-től), persze a 
reflektív programozás ennél többről szól, lépjünk előre egyet: mi lenne, ha az objektumot úgy készítenénk el, 
hogy egyáltalán nem írjuk le a new operátort: 


using System; 

using System.Reflection; // erre a névtérre szükség van 

eláss Test 

{ 

} 

eláss Program 

{ 

static public void Main(string[ ] args) 

{ 

Type type = Assembly. GetCallingAssembly().GetType("Test"); 
var t = Activator .Createlnstance(type); 

Console. WriteLine(t.GetType()); // Test 

Console. ReadKey(); 

} 

} 


Megjegyzendő, hogy fordítási időben semmilyen ellenőrzés sem történik a példányosítandó osztályra nézve, így 
ha elgépeltünk valamit, az bizony kivételt fog dobni futáskor (System.ArgumentNullException). 
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Állománykezelés 


Ebben a fejezetben megtanulunk fájlokat írni/olvasni és megtanuljuk a könyvtárstruktúra állapotának 
lekérdezését illetve módosítását is. 


Olvasás/írás fájlból/fájlba 

A .NET számos osztályt biztosít számunkra, amelyekkel fájlokat tudunk kezelni. Ebben a fejezetben a 
leggyakrabban használtakkal ismerkedünk meg. Kezdjük egy fájl megnyitásával és tartalmának a képernyőre 
írásával. Legyen pl. a szöveges fájl tartalma a következő: 


alma 

körte 

dió 

csákány 

pénz 

könyv 


A fájlnak a futtatható programunk mellett kell lennie, vagy teljes elérési utat kell megadnunk. Visual Studio-ban 
például hozzáadhatunk egy „Text File"-t a projekthez (jobb klikk, majd Add New Item), ezután a fájlon jobb 
gombbal kattintva Properties, és a Copy To Output Directory sorban válasszuk a Copy Always lehetőséget! A 
program pedig: 


using System; 
using System.10; 

eláss Program 

{ 

static public void Main(string[ ] args) 

{ 

FileStream fs = new FileStreamC'test.txt", FileMode.Open) ; 
StreamReader sr = new StreamReader(fs); 

string s = sr.ReadLine(); 
while (s != null) 

{ 

Console.WriteLine(s); 
s = sr.ReadLineQ; 

} 

sr.Close(); 

fs.Close(); 

Console. ReadKey(); 

} 

} 


Az 10 osztályok a System.10 névtérben vannak. A C# ún. stream-eket, adatfolyamokat használ az 10 műveletek 
végzéséhez. Az első sorban megnyitottunk egy ilyen folyamot, és azt is megmondtuk, hogy mit akarunk tenni 
vele. 

A FileStream konstruktorának első paramétere a fájl neve (ha nem talál ilyen nevű fájlt, akkor kivételt dob a 
program). Amennyiben nem adunk meg teljes elérési utat, akkor automatikusan a saját könyvtárában fog 
keresni a program. Fia külső könyvtárból szeretnénk megnyitni az állományt, akkor azt a következőképpen 
tehetjük meg: 
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FileStream fs = new FileStream("C :\\Dirl\\Dir2\\test .txt"., FileMode.Open); 


Azért használunk dupla backslash-t (\), mert ez egy ún. escape karakter, önmagában nem lehetne használni 
(persze ez nem azt jelenti, hogy minden ilyen karaktert kettőzve kellene írni, minden speciális karakter előtt a 
backslash-t kell használnunk). 

Egy másik lehetőség, hogy az „at" jelet (@) használjuk az elérési út előtt, ekkor nincs szükség dupla 
karakterekre, mivel mindent normális karakterként fog értelmezni: 


FileStream fs = new FileStream(@"C:\Dirl\Dir2\test.txt", FileMode.Open); 


A FileMode enum-nak a következő értékei lehetnek: 


Create 

Létrehoz egy új fájlt, ha már létezik, a tartalmát kitörli. 

CreateNew 

Ugyanaz, mint az előző, de ha már létezik a fájl, akkor 
kivételt dob. 

Open 

Megnyit egy fájl, ha nem létezik, kivételt dob. 

OpenOrCreate 

Ugyanaz, mint az előző, de ha nem létezik, akkor 
létrehozza a fájlt. 

Append 

Megnyit egy fájlt, és automatikusan a végére 
pozícionál. Fia nem létezik, létrehozza. 

Truncate 

Megnyit egy létező fájlt, és törli a tartalmát. Ebben a 
módban a fájl tartalmát nem lehet olvasni (egyébként 
kivételt dob). 


A FileStream konstruktorának további két paramétere is lehet, amelyek érdekesek számunkra (tulajdonképpen 
15 különböző konstruktora van), mindkettő felsorolt típus. Az első a FileAccess, amellyel beállítjuk, hogy 
pontosan mit akarunk csinálni az állománnyal: 


Read 

Olvasásra nyitja meg. 

Write 

írásra nyitja meg. 

ReadWrite 

Olvasásra és írásra nyitja meg 


A fenti példát így is írhattuk volna: 


FileStream fs = new FileStream("test.txt"j FileMode. Open^ FileAccess. Read); 


Végül a FileShare-rel azt állítjuk be, ahogy más folyamatok férnek hozzá a fájlhoz: 


Nőne 

Más folyamat nem férhet hozzá a fájlhoz, amíg azt be 
nem zárjuk. 

Read 

Más folyamat olvashatja a fájlt. 

Write 

Más folyamat írhatja a fájlt. 

ReadWrite 

Más folyamat írhatja és olvashatja is a fájlt. 

Delete 

Más folyamat törölhet a fájlból (de nem magát a fájlt). 

Inheritable 

A gyermek processzek is hozzáférhetnek a fájlhoz. 


Fia a fenti programot futtatjuk, akkor előfordulhat, hogy az ékezetes karakterek helyett kérdőjel jelenik meg. Ez 
azért van, mert az éppen aktuális karaktertábla nem tartalmazza ezeket a karaktereket, ez tipikusan nem 
magyar nyelvű operációs rendszer esetén fordul elő. A megoldás, hogy kézzel állítjuk be a megfelelő táblát, ezt 
a StreamReader konstruktorában tehetjük meg (a tábla pedig iso-8859-2 néven szerepel): 


StreamReader rs = new StreamReader(fs, Encoding.GetEncoding("iso-8859-2")j false); 


Ehhez szükség lesz még a System.Text névtérre is. 
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Most írjunk is a fájlba. Erre a feladatra a StreamReader helyett a StreamWriter osztályt fogjuk használni: 


using System; 
using System.10; 
using System.Text; 

eláss Program 

{ 

static public void Main(string[ ] args) 

{ 

FileStream fs = new FileStream("Test.txt"j FileMode.Open, FileAccess. Write, 
FileShare.None); 

StreamWriter sw = new StreamWriter(fs); 

Random r = new Random(); 

fór (int i = 0; i < 10; ++i) 

{ 

sw.Write(r.Next()); 

sw.Write( Environment .NewLine); 

} 

sw.Close(); 

fs.Close(); 

Console. ReadKeyQ; 

} 

} 


Az Environment.NewLine egy „újsor karaktert" (Carriage Return és Line Feed) ad vissza. Bináris fájlok 
kezeléséhez a BinaryReader/BinaryWriter osztályokat használhatjuk: 


using System; 
using System.10; 
using System.Text; 

eláss Program 

{ 

static public void Main(string[ ] args) 

{ 

BinaryWriter bw = new BinaryWriter(File.Create("file.bin")); 

fór (int i = 0; i < 100; ++i) 

{ 

bw.Write(i); 

} 

bw.Close(); 

BinaryReader br = new BinaryReader(File.Open("file.bin", FileMode.Open)); 

while (br.PeekChar() != -1) 

{ 

Console. WriteLine(br.Readlnt32()); 

} 

br.Close(); 

Console. ReadKeyQ; 

} 

} 
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Készítettünk egy bináris fájlt, és beleírtuk a számokat egytől százig. Ezután megnyitottuk, és elkezdtük kiolvasni 
a tartalmát. A PeekChar metódus a soron következő karaktert (byte-ot) adja vissza, illetve -1-et, ha elértük a 
fiié végét. A folyambeli aktuális pozíciót nem változtatja meg. 

A cikluson belül van a trükkös rész. A ReadTípusnév metódus a megfelelő típusú adatot adja vissza, de vigyázni 
kell vele, mert ha nem megfelelő méretű a beolvasandó adat, akkor hibázni fog. A fenti példában, ha a 
ReadString metódust használtuk volna, akkor kivétel (EndOfStreamException) keletkezik, mivel a kettő nem 
ugyanakkora mennyiségű adatot olvas be. Az egész számokat kezelő metódus nyílván működni fog, hiszen 
tudjuk, hogy számokat írtunk ki. 

Eddig kézzel zártuk le a stream-eket, de ez nem olyan biztonságos, mivel gyakran elfelejtkezik róla az ember. 
Használhatjuk ehelyett a using blokkokat, amelyek ezt automatikusan megteszik. Fent például írhatnánk ezt is: 


using (BinanyWniten bw = new BinaryWriter(File.Create("file.bin"))) 

{ 

fon (int i = 0; i < 100; ++i) 

{ 

bw.Wnite(i); 

} 

} 


Könyvtárstruktúra kezelése 

A fájlok mellett a .NET a könyvtárstruktúra kezelését is támogatja. A System.10 névtér ebből a szempontból két 
részre oszlik: információs és operációs eszközökre. Előbbiek (ahogyan a nevük is sugallja) információt 
szolgáltatnak, míg az utóbbiak (többségükben statikus metódusok) bizonyos műveleteket (új könyvtár 
létrehozása, törlése stb.) végeznek a fájlrendszeren. Első példánkban írjuk ki mondjuk a C meghajtó gyökerének 
könyvtárait: 


using System; 
using System.10; 

eláss Program 

{ 

static public void Main(string[ ] args) 

{ 

foreach (string s in Directory.GetDirectories("C:\\")) 

{ 

Console.WriteLine(s); 

} 

Console. ReadKey(); 

} 

} 


Természetesen nemcsak a könyvtárakra, de a fájlokra is kíváncsiak lehetünk. A programunk módosított 
változata némi plusz információval együtt ezeket is kiírja nekünk: 


using System; 
using System.10; 

eláss Program 

{ 

static public void PrintFileSystemInfo(FileSystemInfo fsi) 

{ 

if ((fsi.Attributes & FileAttributes .Directory) != 0) 

{ 

Directorylnfo di = fsi as Directorylnfo; 
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Console.WriteLine("Könyvtár: {0}, Készült: {1}"., 
di.FullName, di.CreationTime); 

} 

else 

{ 

Filelnfo fi = fsi as Filelnfo; 

Console.WriteLine("File: {0}, készült: {1}", 
fi.FullName, fi.CreationTime); 

} 

} 

static public void Main(string[ ] args) 

{ 

foreach (string s in Directory.GetDirectories("C:\\")) 

{ 

PrintFileSystemInfo(new DirectoryInfo( s)); 

} 

foreach (string s in Directory.GetFiles("C:\\")) 

{ 

PrintFileSystemInfo(new Filelnfo(s) ); 

} 

Console. ReadKey(); 

} 

} 


Először a mappákon, majd a fájlokon megyünk végig. Ugyanazzal a metódussal írjuk ki az információkat 
kihasználva azt, hogy a Directorylnfo és a Filelnfo is egy közös őstől, a FileSystemlnfo-ból származik (mindkettő 
konstruktora a vizsgált alany elérési útját várja paraméterként), így a metódusban csak meg kell vizsgálni, hogy 
éppen melyikkel van dolgunk, és átkonvertálni a megfelelő típusra. A vizsgálatnál egy „bitenkénti és" műveletet 
hajtottunk végre, hogy ez miért és hogyan működik, annak meggondolása az olvasó feladata. 

Eddig csak információkat kértünk le, most megtanuljuk módosítani is a könyvtárstruktúrát. Arra figyeljünk, hogy 
olyan könyvtárat vagy meghajtót használjunk a program tesztelésére, amelybe joga van írni a programunknak, 
ellenkező esetben kivételt kaphatunk! 


using System; 
using System.10; 

eláss Program 

{ 

static public void Main(string[ ] args) 

{ 

string dirPath = "C:\\test"; 

string filePath = dirPath + "\\file.txt"; 

// ha nem létezik a könyvtár 
if (Directory .Exists(dirPath) == false) 

{ 

// akkor elkészítjük 

Directory .CreateDirectory(dirPath); 

} 

Filelnfo fi = new Filelnfo(filePath); 

// ha nem létezik a fiié 
if (fi.Exists == false) 

{ 

// akkor elkészítjük és írunk bele 
StreamWriter sw = fi.CreateText(); 
sw.WriteLine( "Dió" ); 
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sw.WriteLine("Alma"); 
sw.Close(); 

} 

} 

} 


A Filelnfo CreateText metódusa egy StreamWriter objektumot ad vissza, amellyel írhatunk egy szöveges fájlba. 


In-memory streamek 

A .NET a MemoryStream osztályt biztosítja számunkra, amellyel memóriabeli adatfolyamokat 
írhatunk/olvashatunk. Mire is jók ezek a folyamok? Gyakran van szükségünk arra, hogy összegyűjtsünk nagy 
mennyiségű adatot, amelyeket majd a folyamat végén ki akarunk írni a merevlemezre. Egy tömb vagy egy lista 
nem nyújtja a megfelelő' szolgáltatásokat, előbbi rugalmatlan, utóbbi memóriaigényes, ezért a legegyszerűbb, 
ha közvetlenül a memóriában tároljuk el az adatokat. A MemoryStream osztály jelentősen megkönnyíti a 
dolgunkat, mivel lehetőséget ad közvetlenül fájlba írni a tartalmát. A következő program erre mutat példát: 


using System; 
using System.10; 

eláss Program 

{ 

static public void Main(string[ ] args) 

{ 

MemoryStream mstream = new MemoryStream(); 
StreamWriter sw = new StreamWriter (mstream); 

fór (int i = 0; i < 1000; ++i) 

{ 

sw.WriteLine(i); 

} 

sw.Flush(); 

FileStream fs = File.Create("D:\\inmem.txt"); 
mstream.WriteTo(fs); 

sw.Close(); 
fs.Close(); 
mstream.Close(); 

} 

} 


A MemoryStream-re „ráállítottunk" egy StreamWriter objektumot. Miután minden adatot a memóriába írtunk, 
a Flush metódussal (amely egyúttal kiüríti a StreamWriter-t is) létrehoztunk egy fájlt és a MemoryStream 
WriteTo metódusával kiírtuk belé az adatokat. 


XML 


Az XML általános célú leírónyelv, amelynek elsődleges célja strukturált szöveg és információ megosztása az 
interneten keresztül. Lássunk egy példát: 


<?xml version="1.0" encoding="utf-8" ?> 
<list> 

<item>l</item> 
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<item>2</item> 

<item>3</item> 

</list> 


Az első sor megmondja, hogy melyik verziót és milyen kódolással akarjuk használni, ezután következnek az 
adatok. Minden XML dokumentum egyetlen gyökérelemmel rendelkezik (ez a fenti példában a <list>), 
amelynek minden más elem a gyermekeleme (egyúttal minden nem-gyökérelem egy másik elem gyermeke kell 
legyen, ez nem feltétlenül jelenti a gyökérelemet). Minden elemnek rendelkeznie kell nyitó (<list>) és záró 
(</list>) tagekkel. Üres elemeknél ezeket egyszerre is deklarálhatjuk (<üres />). Az egyes elemek tárolhatnak 
attribútumokat a következő formában: 


<item value="10" /> 

<item value="10"x/item> 


Itt mindkét forma legális. A .NET Framework erősen épít az XML-re, mind offline (konfigurációs fájlok, in- 
memory adatszerkezetek), mind online (SOAP alapú információcsere stb.) téren. 

A számunkra szükséges osztályok a System.Xml névtérben vannak, a két legalapvetőbb ilyen osztály az 
XmlReader és az XmlWriter. Ezeknek az absztrakt osztályoknak a segítségével hajthatóak végre a szokásos - 
irás/olvasás - műveletek. 

Először nézzük meg, hogyan tudunk beolvasni egy XML fájlt. A megnyitáshoz az XmlReader egy statikus 
metódusát, a Create-et fogjuk használni, ez egy streamtől kezdve egy szimpla fájlnévig mindent elfogad: 


XmlReader reader = XmlReader. Create("test.xml"); 


Függetlenül attól, hogy az XmlReader egy absztrakt osztály, tudjuk példányosítani, mégpedig azért, mert 
ilyenkor valójában egy XmlTextReaderlmpI típusú objektum jön létre, amely az XmlReader egy belső, internál 
elérésű leszármazottja (tehát közvetlenül nem tudnánk példányosítani). Miután tehát megnyitottuk a fájlt, 
végig tudunk iterálni a tartalmán: 


while (reader.ReadQ) 

{ 

switch (reader.NodeType) 

{ 

case XmlNodeType. Element: 

Console.WriteLine( "<{0}>", reader.Name); 
break; 

case XmlNodeType. EndElement: 

Console.WriteLine( "</{0}>" , reader.Name); 
break; 

case XmlNodeType. Text: 

Console.WriteLine(reader.Value); 
break; 
default: 
break; 

}; 

} 


Az XmlReader NodeType tulajdonsága egy XmlNodeType felsorolás egy tagját adja vissza, a példában a 
legegyszerűbb típusokat vizsgáltuk, és ezek függvényében írtuk ki a fájl tartalmát. A következő példában 
használni fogjuk az XmlWriter osztály egy leszármazottját, az XmlTextWriter-t, ugyanis a fájlt kódból fogjuk 
létrehozni: 


XmlTextWriter writer = new XmlTextWriter("newxml.xml" J Encoding.UTF8); 
writer.Formatting = Formatting. Indented; 


Az Encoding felsorolás használatához szükséges a System.Text. A Formatting tulajdonság az Xml fájloktól 
megszokott hierarchikus szerkezetet fogja megteremteni (ennek az értékét is beállíthatjuk). 
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writer.WriteStartDocument(); 

writer.WriteComment(DateT íme. Now.ToString()); 

Elkezdtük az adatok feltöltését, és beszúrtunk egy kommentet is. A fiié tartalma most a következő: 

<?xml version="1.0" encoding="utf-8"?> 

<! --2012.07.24. 7:05:24- -> 

A fájl ebben a példában személyek adatait fogja tartalmazni: 

wniten.WniteStartElement( "PersonsList" ); 

writer.WriteStartElement( "Persón") ; 

writer.WriteElementString( "Name"j "Reiter István"); 

writer.WriteElementString( "Age", "26") ; 

writer.WriteEndElement(); 

A StartElement egy új „tagcsoportot" kezd a paramétereként megadott névvel, a WriteElementString pedig 
feltölti azt értékekkel, kulcs-érték párokkal. A fájl: 

<?xml version="1.0" encoding="utf-8"?> 

<! --2012.07.24. 7:07:04--> 

<PersonsList> 

<Person> 

<Name>Reiter Istvan</Name> 

<Age>22</Age> 

</Person> 

</PersonsList> 

Az egyes tagekhez attribútumokat is rendelhetünk: 

writer.WriteStartElement( "PersonsList") ; 
writer.WriteAttributeString("Note"j "List of persons"); 

Első paraméter az attribútum neve, utána pedig a hozzá rendelt érték jön. Ekkor a fájl így alakul: 

<?xml version="1.0" encoding="utf-8"?> 

<! --2012.07.24. 7:08:03- -> 

<PersonsList Note="List of persons"> 

<Person> 

<Name>Reiter Istvan</Name> 

<Age>22</Age> 

</Person> 

</PersonsList> 

Az XmlReader rendelkezik néhány MoveTo előtaggal rendelkező metódussal, ezekkel a fájl egy olyan pontjára 
tudunk navigálni, amely megfelel egy feltételnek. Néhány példa: 

bool 1 = reader.MoveToAttribute("Note"); 

Ez a metódus a paramétereként megadott attribútumra állítja a reader objektumot, és igaz értékkel tér vissza, 
ha létezik az attribútum. Ellenkező esetben a pozíció nem változik, és a visszatérési érték hamis lesz. 

reader.MoveToContent(); 


Ez a metódus a legközelebbi olyan csomópontra ugrik, amely tartalmaz adatot is, ekkor az XmlReader (vagy 
leszármazottainak) Value tulajdonsága ezt az értéket fogja tartalmazni. 
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A MoveToElement metódus visszalép arra a csomópontra, amely azt az attribútumot tartalmazza, amelyen a 
reader áll (értelemszerűen következik, hogy az eló'zó' kettő' metódust gyakran használjuk együtt): 


while (reader.ReadQ) 

{ 

if (reader.HasAttributes) 

{ 

fór (int i = 0; i < reader.AttributeCount; ++i) 

{ 

reader.MoveToAttribute(i); 

Console.WriteLine( "{0} {1}", reader.Name, reader.Value); 

} 

reader.MoveToElement(); 

} 

} 


A HasAttribute metódussal megtudakoljuk, hogy van-e a csomóponton attribútum, utána pedig az 
AttributeCount tulajdonság segítségével (amely azoknak a számát adja vissza) végigiterálunk rajtuk. Miután 
végeztünk, visszatérünk a kiindulási pontra (hogy a Read metódus tudja végezni a dolgát). 

Említést érdemelnek még a MoveToFirstAttribute és a MovetoNextAttribute metódusok, amelyek nevükhöz 
méltóan az első illetve a „következő" attribútumra pozícionálnak. Módosítsuk egy kicsit az előző példát: 


fór (int i = 0; i < reader.AttributeCount; ++i) 

{ 

//reader.MoveToAttribute(i); 
reader.MoveToNextAttribute(); 

Console.WriteLine("{0} {1}", reader.Name, reader.Value); 

} 


Végül, de nem utolsósorban a Skip metódus maradt, amely átugorja egy csomópont gyermekeit, és a következő 
azonos szinten lévő csomópontra ugrik. 


XMLDOM 

Eddig az XML állományokat hagyományos fájlként kezeltük, ennél azonban van egy némileg kényelmesebb 
lehetőségünk is. Az XML DÓM (Document Object Model) a fájlokat hierarchikus felépítésük szerint kezeli. Az 
osztály amelyen keresztül elérjük a DOM-ot az XmIDocument lesz. Egy másik fontos osztály, amelyből 
egyébként maga az XmIDocument is származik, az XmlNode. Egy XML fájl egyes csomópontjait egy-egy 
XmlNode objektum fogja jelképezni. 

Ahogy azt már megszokhattuk, az XmIDocument számos forrásból táplálkozhat, pl. stream vagy egyszerű 
fájlnév. A forrás betöltését az XmIDocument Load illetve LoadXml metódusaival végezzük: 


XmIDocument xdoc = new XmlDocument(); 
xdoc.Load( "test. xml"); 


Egy XmIDocument bejárható foreach ciklussal a ChildNodes tulajdonságon keresztül, amely egy XmlNodeList 
objektumot ad vissza. Persze nem biztos, hogy léteznek gyermekei, ezt a HasChildNodes tulajdonsággal tudjuk 
ellenőrizni. A következő forráskódban egy XmIDocument első szinten lévő gyermekeit járjuk be: 


using System; 
using System.Xml; 

eláss Program 

{ 

static public void Main(string[ ] args) 
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{ 

XmlDocument xdoc = new XmlDocument (); 
xdoc.Load ("test.xml") ; 

foreach (XmlNode node in xdoc.ChildNodes) 

{ 

Console.WriteLine(node.Name); 

} 

Console. ReadKeyQ; 

} 

} 


Az XmlDocument a ChildNodes tulajdonságát az XmlNode osztálytól örökli (ugyanígy a HasChildNodes-t is, 
amely igaz értéket tartalmaz, ha léteznek gyermek-elemek), így az egyes XmlNode-okat bejárva a teljes „fát" 
megkaphatjuk. 

Most nézzük meg, hogyan tudunk manipulálni egy dokumentumot! Eló'ször hozzunk létre egy új fájlt: 


using System; 
using System.Xml; 

eláss Program 

{ 

static public void Main(string[ ] args) 

{ 

XmlDocument xdoc = new XmlDocument(); 

XmlElement element = xdoc.CreateElement("Test"); 
XmlText text = xdoc.CreateTextNode( "Hello XML DÓM!"); 

XmlNode node = xdoc.AppendChild(element); 
node.AppendChild(text); 

xdoc.Savé( "domtest.xml" ); 

Console. ReadKeyQ; 

} 

} 


Az XmlText illetve XmlElement osztályok is az XmlNode leszármazottai. A Savé metódussal el tudjuk menteni a 
dokumentumot, akár fájlnevet, akár egy streamet megadva. A fenti kód eredménye a következő lesz: 


<Test>Hello XML DÓM! </Test> 


A CIoneNode metódussal már létező csúcsokat „klónozhatunk": 


XmlNode source = xdoc.CreateNode(XmlNodeType.Element, "test", "test"); 
XmlNode destination = source.CloneNode(false); 


A metódus egyetlen paramétert vár, amely jelzi, hogy a csúcs gyermekeit is átmásoljuk-e. Két másik 
metódusról is megemlékezünk, első a RemoveChild, amely egy létező csúcsot távolít el a csúcsok listájából, a 
másik pedig a ReplaceChild, amely felülír egy csúcsot. 

Az XmlDocument eseményeket is szolgáltat, amelyek segítségével teljes körű felügyeletet nyerhetünk. Kezeljük 
le például azt az eseményt, amikor egy új csúcsot adunk hozzá: 


XmlDocument xdoc = new XmlDocument(); 

XmlNodeChangedEventHandler handler = null; 
handler = (sender, e) => 
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{ 

Console. WriteLine(e.Node.Value); 

}; 

xdoc.Nodelnserting += handler; 


XML SZERIALIZÁCIÓ 


Mi is az a szérializálás? A legegyszerűbben egy példán keresztül lehet megérteni a fogalmat. Képzeljük el, hogy 
írtunk egy játékot, és a játékosok pontszámát szeretnénk eltárolni! Az elért pontszám mellé jön a játékos neve 
és a teljesítés ideje is. Ez elsó're semmi különös, hiszen simán kiírhatjuk az adatokat egy fájlba, majd 
visszaolvashatjuk onnan. Egy apró gond mégis van, mégpedig az, hogy ez elég bonyolult feladat: figyelni kell a 
beolvasott adatok típusára, formátumára stb. 

Nem lenne egyszerűbb, ha a kiírt adatokat meg tudnánk feleltetni egy osztálynak? Ezt megtehetjük, ha 
készítünk egy megfelelő osztályt, amelyet szérializálva kiírhatunk XML formátumba, és onnan vissza is 
olvashatjuk (ezt deszérializálásnak hívják). Természetesen a szérializálás jelentősége ennél sokkal nagyobb, és 
nemcsak XML segítségével tehetjük meg. Tulajdonképpen a szérializálás annyit tesz, hogy a memóriabeli 
objektumainkat egy olyan szekvenciális formátumba (pl. bináris vagy most XML) konvertáljuk, amelyből vissza 
tudjuk alakítani az adatainkat. 

Már említettük, hogy több lehetőségünk is van a szerializációra, ezek közül az XML a legáltalánosabb, hiszen ezt 
más környezetben is felhasználhatjuk. 

Kezdjük egy egyszerű példával (hamarosan megvalósítjuk a pontszámos példát is), szérializáljunk egy 
hagyományos beépített objektumot: 


FileStream fstream = new FileStneam("senxml.xml"j FileMode.Create); 
XmlSerializer ser = new XmlSerializer(typeof (DateTime) ); 
ser.Serialize(fstream, DateTime .Now); 


Ezután létrejön egy XML fiié, benne a szérializált objektummal: 


<?xml version="1.0"?> 

<dateTime>2008-10-23T16:19:44.53125+02 :00</dateTime> 


Az XmlSerializer a System.Xml.Serialization névtérben található. A deszérializálás hasonlóképpen működik: 


FileStream fstream = new FileStreamC'serxml.xml", FileMode.Open) ; 
XmlSerializer ser = new XmlSerializer(typeof (DateTime ) ); 

DateTime deser = (DateTime)ser.Deserialize(fstream); 


Most már eleget tudunk ahhoz, hogy készítsünk egy szérializálható osztályt. Egy nagyon fontos dolgot kell 
megjegyeznünk: az osztálynak csakis a publikus tagjai szérializálhatóak, a priváté vagy protected elérésűek 
automatikusan kimaradnak (emellett az osztálynak magának is publikus elérésűnek kell lennie). Ezeken kívül 
még szükség lesz egy alapértelmezett konstruktorra is (a deszérializáláshoz, hiszen ott még nem tudjuk, hogy 
milyen objektumról van szó). 


public eláss ScoreObject 

{ 

public ScoreObject() 

{ 

} 

priváté string playername; 

[ XmlElement ( "PlayerName") ] 
public string PlayerName 
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{ 

get { return playername; } 
set { playername = value; } 

} 

priváté int score; 

[ XmlElement ( "Score" )] 
public int Score 
{ 

get { return score; } 
set { score = value; } 

} 

priváté DateTime date; 

[ XmlElement ( "Date" )] 
public DateTime Date 
{ 

get { return date; } 
set { date = value; } 

} 


Az egyes tulajdonságoknál beállítottuk, hogy az miként jelenjen meg a fájlban (sima element helyett lehet pl. 
attribútum is). Enélkül is lefordulna és működne, de így jobban kezelhető'. Rendben, most szérializáljuk: 


ScoreObject so = new ScoreObject( ); 

so.PlayerName = "Playerl"; 
so.Score = 1000; 
so.Date = DateTime. Now; 

FileStream fstream = new FileStream("scores.xml"j FileMode.Create); 
XmlSerializer ser = new XmlSerializer(typeof (ScoreObject) ); 
ser.Serialize(fstreamj so); 


És az eredmény: 


<?xml version="1.0"?> 

<ScoreObject xmlns :xsi=" http://www. w3.org/2001/XMLSchema-instance 
xmlns :xsd=" http://www.w3.org/2001/XMLSchema"> 
<PlayerName>Playerl</PlayerName> 

< Score >1000< /Score > 

< Date > 2012-07-24T10:31:43.8922442+02: 00</Date> 

</ScoreObject> 
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Konfigurációs fájl használata 


Eddig, amikor egy programot írtunk, minden apró változtatásnál újra le kellett fordítani, még akkor is, ha maga 
a program nem, csak a használt adatok változtak. Sokkal kényelmesebb lenne a fejlesztés és a kész program 
használata is, ha a „külső" adatokat egy külön fájlban tárolnánk. Természetesen ezt megtehetjük úgy is, hogy 
egy sima szöveges fájlt készítünk, és azt olvassuk/írjuk, de a .NET ezt is megoldja helyettünk a konfigurációs 
fájlok bevezetésével. Ezek tulajdonképpen XML dokumentumok, amelyek a következőképpen épülnek fel: 


<?xml version="l 

0" encoding= 

'utf -8" ?> 

<configuration> 



<appSettings> 



<add key="l" 

value="alma" 

/> 

<add key="2" 

value="korte 

/> 

</appSettings> 

</configuration> 




Az első sor egy szabványos XML fiié fejléce, evvel nem kell foglalkoznunk. Sokkal érdekesebb viszont az 
appSettings szekció, ahová már be is raktunk néhány adatot. Az appSettings az általános adatok tárolására 
szolgál, vannak speciális szekciók (pl. adatbázisok eléréséhez), és mi magunk is készíthetünk ilyet (erről 
hamarosan). 

Visual Studio-ban könnyen hozzáadhatunk egy konfigurációs fájlt a projektünkhöz: jobb gombbal kattintsunk a 
projekten, majd az „Add" menüből válasszuk a „New Item" elemet, a listában pedig keressük meg az 
„Application Configuration Fiié" sort! Az OK gombra kattintva létrejön egy App.config nevű fájl a projekten 
belül. Az üres <configuration> szekcióba másoljuk bele a fenti sorokat! 

Még valamit meg kell tennünk: jobb gombbal kattintsunk a projekten belül a References „mappán", majd 
válasszuk az „Add Reference" elemet, majd a .NET fülön a listából keressük ki a System.Configuration 
assemblyt, és az Add gombbal adjuk hozzá a projekthez! Most már írhatunk egy programot, amely felhasználja 
ezt a fájlt: 


using System; 

using System.Configuration; 

eláss Program 

{ 

static public void Main(string[ ] args) 

{ 

string s = ConfigurationManager.AppSettings["l"]; 
Console.WriteLine(s); // alma 
Console. ReadKey(); 

} 

} 


Látható, hogy az AppSettings rendelkezik indexelővei, amely visszaadja a megfelelő értéket a megadott 
kulcshoz. 


Ugyanezt elérhetjük a ConfigurationSettings.AppSettings-szel is, de az már elavult - erre a fordító is 
figyelmeztet, ha használni akarjuk -, csak a korábbi verziók kompatibilitása miatt van még benne a 
frameworkben. 


Az AppSettings indexelője minden esetben stringet ad vissza, tehát ha más típussal akarunk dolgozni, akkor 
konvertálni kell. Vezessünk be a konfig-fájlba egy új kulcs-érték párost: 


<?xml version="1.0"?> 
<configuration> 
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<appSettings> 


<add key="l" 

value="alma"/> 

<add key="2" 

value="korte"/> 

<add key="3" 

value="10"/> 

</appSettings> 


</configuration> 



És használjuk is fel a forrásban: 


using System; 

using System.Configuration; 

eláss Program 

{ 

static public void Main(string[] args) 

{ 

int x = int.Parse(ConfigurationManager.AppSettings["3"]); 
Console.WriteLine(x); // 10 
Console. ReadKeyQ; 

} 

} 


Konfiguráció-szekció készítése 

Egyszerűbb feladatokhoz megteszi a fenti módszer is, de hosszabb programok esetében nem kényelmes mindig 
figyelni a konverziókra. Épp ezért készíthetünk olyan osztályt is, amely egyrészt típusbiztos, másrészt a 
konfigurációs fájlban is megjelenik. 

A következő' példában elkészítünk egy programot, amely konfigurációs fájlból kiolvas egy fájlnevet és a 
kódtáblát, és ezek alapján kiírja az állomány tartalmát. Első lépésként készítsünk egy új osztályt (Add/Class) 
AppDataSection.es néven, amely a következőt tartlamazza: 


using System; 

using System.Configuration; 

public eláss AppDataSection : ConfigurationSection 

{ 

priváté static AppDataSection settings = 
ConfigurationManager .GetSection("AppDataSettings") 
as AppDataSection; 

public static AppDataSection Settings 

{ 

get { return AppDataSection .settings; } 

} 

[ConfigurationProperty("fileName"j IsRequired = true)] 
public string FileName 
{ 

get 

{ 

return this["fileName"] as string; 

} 

set 

{ 

this [ "fileName"] = value; 

} 

} 
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[ConfigunationPnoperty("encodeType", IsRequined = true)] 
public string EncodeType 
{ 

get 

{ 

netunn this["encodeType"] as stning; 

} 

} 


Az osztályt a ConfigurationSection osztályból származtattuk, ennek az indexeló'jét használjuk. Itt arra kell 
figyelni, hogy az AppSettings-szel ellentétben ó' object típussal tér vissza, vagyis muszáj konverziót 
végrehajtani. 


A Settings property segítségével az osztályon keresztül egyúttal hozzáférünk az osztály egy példányához is, így 
soha nem kell példányosítanunk azt. 


A tulajdonságok attribútumával beállítottuk a konfig-fájlban szerepló' nevet, illetve, hogy muszáj megadnunk 
ezeket az értékeket (a DefaultValue segítségével kezdőértéket is megadhatunk). Most jön a konfigurációs 
állomány, itt regisztrálnunk kell az új szekciót: 


<?xml version="1.0" encoding="utf-8"?> 

<configuration> 

<configSections> 

<section name="AppDataSettings" type="AppDataSection, main" /> 
</configSections> 

<AppDataSettings fileName="file .txt" encodeType="iso-8859-2" /> 
</configuration> 


A type tulajdonságnál meg kell adnunk a típus teljes elérési útját névtérrel együtt (ha van), illetve azt az 
assemblyt, amelyben a típus szerepel ez most a projekt neve lesz. 

Most jöjjön az osztály, amely használja az új szekciót! Készítsünk egy DataHandlerClass.es nevű fájlt is: 


using System; 

using System.10; 

using System.Text; 

using System.Configuration; 

public eláss DataHandlerClass 

{ 

public void PnintData() 

{ 

Encoding enc = Encoding.GetEncoding( 

AppDataSection .Settings.EncodeType); 

stning filename = AppDataSection. Settings.FileName; 

using (FileStneam fs = new FileStneam(filename, FileMode.Open)) 

{ 

using (StreamReader sn = new StreamReader(fs , enc, false)) 

{ 

stning s = sn.ReadLine(); 
while (s != null) 

{ 

Console.WniteLine(s); 
s = sn.ReadLine(); 

} 

} 
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} 

} 

} 


Most már könnyen használhatjuk az osztályt: 


using System; 

using System.Configuration; 

eláss Program 

{ 

static public void Main(string[ ] args) 

{ 

DataHandlerClass handler = new DataHandlerClass(); 
handler.PrintData(); 

Console. ReadKeyQ; 

} 

} 
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Hálózati programozás 


A .NET meglehetősen széles eszköztárral rendelkezik hálózati kommunikáció kialakításához. A lista a 
legegyszerűbb hobbiszintű programokban használható szerver-kliens osztályoktól egészen a legalacsonyabb 
szintű osztályokig terjed. Ebben a fejezetben ebből a listából szemezgetünk. 

A fejezethez tartozó forráskódok megtalálhatóak a jegyzethez tartozó Sources\Network könyvtárban. 

Socket 

A socketek számítógépes hálózatok (pl. az Internet) közötti kommunikációs végpontok. Minden socket 
rendelkezik két adattal, amelyek által egyértelműen azonosíthatóak és elérhetőek: ezek az IP cím és a port 
szám. 

Mi az az IP cím? Az Internet az ún. Internet Protocol (IP) szabványa szerint működik. Eszerint a hálózaton lévő 
minden számítógép egyedi azonosítóval - IP címmel rendelkezik (ugyanakkor egy számítógép több címmel is 
rendelkezhet, ha több hálózati hardvert használ). Egy IP cím egy 32 bites egész szám, amelyet 8 bites részekre 
osztunk (pl.: 123.255.0.45), ezáltal az egyes szekciók legmagasabb értéke 255 lesz (ez a jellemző az IP negyedik 
generációjára vonatkozik, az új hatos generáció már 128 bites címeket használ, igaz ez egyelőre kevésbé 
elterjedt (a .NET támogatja az IPv4 és IPv6 verziókat is)). 

Az IP címet tekinthetjük az ország/város/utca/házszám négyesnek, míg a portszámmal egy szobaszámra 
hivatkozunk. A portszám egy 16 bites előjel nélküli szám 1 és 65535 között. A portszámokat ki lehet „sajátítani", 
vagyis ezáltal biztosítják a nagyobb szoftvergyártók, hogy ne legyen semmilyen ütközés a termék használatakor. 
A portszámok hivatalos regisztrációját az Internet Assigned Numbers Authority (IANA) végzi. 

Az 1 és 1023 közötti portokat ún. well-knowed portként ismerjük, ezeken olyan széles körben elterjedt 
szolgáltatások futnak, amelyek a legtöbb rendszeren megtaláhatóak (operációs rendszertől függetlenül). Pl. a 
böngészők a HTTP protokollt a 80-as porton érik el, a 23 a Telnet, míg a 25 az SMTP szerver portszáma (ezektől 
el lehet - és biztonsági okokból a nagyobb cégek el is szoktak - térni, de a legtöbb számítógépen ezekkel az 
értékekkel találkozunk). 

Az 1024 és 49151 közötti portokat regisztrált portoknak nevezik, ezeken már olyan szolgáltatásokat is 
felfedezhetünk amelyek operációs rendszerhez (is) kötöttek pl. az 1433 a Microsoft SQL Server portja, ami 
értelemszerűen Windows rendszer alatt fut. Ugyanitt megtalálunk szoftverhez kötött portot is, pl. a World of 
Warcraft a 3724 portot használja. Ez az a tartomány amit az IANA kezel. 

Az e felettieket dinamikus vagy privát portoknak nevezik, ezt a tartományt nem lehet lefoglalni, 
programfejlesztés alatt célszerű ezeket használni. 

Mielőtt nekiállunk a Socket osztály megismerésének, játsszunk egy kicsit az IP címekkel! Azt tudjuk már, hogy a 
hálózaton minden számítógép saját címmel rendelkezik, de számokat viszonylag nehéz megjegyezni, ezért 
feltalálták a domain-név vagy tartománynév intézményét, amely „ráül" egy adott IP címre, vagyis ahelyett, 
hogy 65.55.21.250 írhatjuk azt, hogy www.micmsoft.com. A következő programunkban lekérdezzük egy 
domain-név IP címét és fordítva. Ehhez a System.Net névtér osztályai lesznek segítségünkre: 


using System; 
using System.Net; 

eláss Program 

{ 

static public void Main(string[ ] args) 

{ 

IPHostEntry hostl = Dns .GetHostEntry( "www. microsoft.com"); 

foreach (IPAddress ip in hostl.AddressList) 

{ 

Console.WriteLine(ip.ToString()); 

} 

IPHostEntry host2 = Dns.GetHostEntry("91.120.22.150"); 
Console.WriteLine(host2.HostName); 
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Console. ReadKeyQ; 

} 

} 


Most már ideje nagyobb kihívás után nézni, elkészítjük az első szerverünket. A legegyszerűbb módon fogjuk 
csinálni a beépített TcpListener osztállyal, amely a TCP/IP protokollt használja (erről hamarosan 
részletesebben). Nézzük meg a forrást: 


using System; 

using System.Net; 

using System.Net.Sockets; 

eláss Program 

{ 

static public void Main(string[ ] args) 

{ 

IPAddress ip = IPAddress. Parse("127. 0.0.1"); 
int port = 5000; 

IPEndPoint endPoint = new IPEndPoint(ip, port); 

TcpListener server = new TcpListener(endPoint); 

server.Start(); 

Console. WriteLine( "A szerver elindult!"); 
Console. ReadKeyQ; 

} 

} 


A 127.0.0.1 egy speciális cím, ez az ún. localhost, vagyis a „helyi" cím, amely jelen esetben a saját 
számítógépünk (ehhez Internet kapcsolat sem szükséges, mindig rendelkezésre áll). Ez az ip cím lesz az, ahol a 
szerver bejövő kapcsolatokra fog várni (értelemszerűen ehhez az IP címhez csak a saját számítógépünkről 
tudunk kapcsolódni, ha egy távoli gépet is szeretnénk bevonni, akkor szükség lesz a „valódi" IP -re, ezt pl. a 
parancssorba beírt ipconfig paranccsal tudhatjuk meg). 

A „szervert" a Stop metódussal állíthatjuk le. 


using System; 

using System.Net.Sockets; 

using System.Net; 

namespace Server 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

TcpListener server = null; 

try 

{ 

IPAddress ipAddr = IPAddress. Parse("127. 0.0.1"); 
int portNum = 5000; 

IPEndPoint endPoint = new IPEndPointCipAddr, portNum); 

server = new TcpListener(endPoint); 
server.Start(); 

Console. WriteLine("A szerver elindult!"); 
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} 


} 


Console. ReadKeyQ; // várunk bejövő kapcsolatra 

} 

catch (Exception e) 

{ 

Console .WriteLine(e.Message); 

} 

finally 

{ 

server.Stop(); 

Console. WriteLine("A szerver leállt!"); 

} 

} 


A TcpListener konstruktorában meg kell adnunk egy végpontot a szervernek, ahol figyelheti a bejövő 
kapcsolatokat, ehhez szükségünk lesz egy IP címre és egy portszámra. Előbbit az IPAddress.Parse statikus 
metódussal egy karaktersorozatból nyertük ki. 

A Console.ReadKey azért kell, mert különben ugranánk is tovább a finally ágra, ahol lezárjuk a szervert. 

A következő lépésben bejövő kapcsolatot fogadunk, ehhez viszont szükségünk lesz egy kliensre is, őt a 
TcpCIient osztállyal készítjük el, amely hasonlóan működik, mint a párja, szintén egy cím-port kettősre lesz 
szükségünk (de most nem kell végpontot definiálnunk): 


using System; 

using System.Net; 

using System.Net.Sockets; 

eláss Program 
{ 


static public void Main(string[ ] args) 

{ 

TcpCIient Client = null; 

try 

{ 

Client = new TcpClient("127. 0.0.1", 5000); 
Console. WriteLine(client.Connected); // true 

} 

catch (Exception e) 

{ 

Console.WriteLine(e.Message); 

} 

finally 

{ 


Client .Close(); 

} 


Console. ReadKey(); 

} 

} 


A TcpCIient-nek vagy a konstruktorban rögtön megadjuk az elérni kívánt szerver nevét és portját (és ekkor 
azonnal csatlakozik is), vagy meghívjuk az alapértelmezett konstruktőrt, és a Connect metódussal elhalasztjuk a 
kapcsolódást egy későbbi időpontra (természetesen ekkor neki is meg kell adni a szerver adatait). 

Ahhoz, hogy a szervert és klienst is egyszerre elindíthassuk anélkül, hogy két Visual Studio-t nyitnánk, először 
készítsünk egy külön projektet a kliens vagy szerver számára! Ezután kattintsunk jobb gombbal a Solution-ön 
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(nem a projekten), és válasszuk a „Set StartUp Projects" menüpontot! Jelöljük be a „Multiple StartUp Projects" 
kapcsolót és a kívánt projektek Action oszlopában állítsuk a megadott értéket Start-ra! Figyeljünk arra, hogy a 
szervert tartalmazó projekt legyen elöl! 

Most már elindíthatjuk a programjainkat, és a kliens ablakában a True feliratot fogjuk látni, hiszen a Connected 
tulajdonság azt mondja meg, hogy van-e aktív kapcsolat vagy sem. 

Ahhoz, hogy a szerver kezelni is tudja a kliensünket (eddig csak kapcsolatot létesítettünk), meg kell mondanunk 
neki, hogy várjon, amíg bejövő kapcsolat érkezik. Ezt a TcpListener osztály AcceptTcpCIient metódusával 
tehetjük meg: 


TcpClient Client = server.AcceptTcpClient(); 


Persze szerveroldalon egy TcpClient objektumra lesz szükségünk, ezt adja vissza a metódus. A programunk jól 
működik, de nem csinál túl sok mindent. A következő lépésben adatokat küldünk a szerverről a kliensnek. 
Nézzük az „új" szervert: 


using System; 
using System.Text; 
using System.Net.Sockets; 
using System.Net; 

namespace Server 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

TcpListener server = null; 

NetworkStream stream = null; 

try 

{ 

IPAddress ipAddr = IPAddress.Parse("127.0.0.1"); 
int portNum = 5000; 

IPEndPoint endPoint = new IPEndPoint(ipAddr, portNum); 

server = new TcpListener(endPoint); 
server.Start(); 

Console.WriteLine("A szerver elindult!"); 

TcpClient Client = server.AcceptTcpClient(); 

byte[] data = Encoding. ASCII .GetBytes("Hello kliens..."); 

stream = Client. GetStreamQ; 
stream.Write(data, 0 , data.Length); 

} 

catch (Exception e) 

{ 

Console.WriteLine(e.Message); 

} 

finally 

{ 

stream.Close(); 
server. StopQ; 

} 

} 

} 

} 
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Az elküldeni kívánt üzenetet byte-tömb formájában kell továbbítanunk, mivel a TCP/IP byet-ok sorozatát 
továbbítja, ezért számára emészthető formába kell hoznunk az üzenetet. A fenti példában a legegyszerűbb, 
ASCII kódolást választottuk, de mást is használhatunk; a lényeg, hogy tudjuk byte-onként küldeni 
(értelemszerűen mind a kliens, mind a szerver ugyanazt a kódolást kell használja). 

A NetworkStream ugyanolyan adatfolyam, amit a fájlkezeléssel foglalkozó fejezetben megismertünk, csak 
éppen az adatok most a hálózaton keresztül „folynak" át. A Write metódus három paramétere közül az első a 
küldeni kívánt adat (byte-tömb formában), utána a kezdőpozició (ebben azesetben az elejétől kezdve írunk, 
vagyis nulla), majd a hossz következik. 

A szerver az üzenet elküldése után leáll, a program pedig befejezi futását. Fontos, hogy az erőforrásokat 
megfelelő sorrendben zárjuk le, először a streamet és csak utána következik maga szerver. Lássuk a kliens 
oldalt: 


using System; 
using System.Net; 
using System.Net.Sockets; 
using System.Text; 

eláss Program 

{ 

static public void Main(string[ ] args) 

{ 

TcpClient Client = null; 

NetworkStream stream = null; 

try 

{ 

Client = new TcpClient("127. 0.0.1", 5000); 
byte[] data = new byte[128]; 
stream = Client.GetStream(); 

int length = stream.Read(data, 0, data.Length); 

Console.WriteLine("A szerver üzenete: {0}", 
Encoding. ASCII.GetString(data)); 

} 

catch (Exception e) 

{ 

Console.WriteLine(e.Message); 

} 

finally 

{ 

stream.Close(); 

Client .Close(); 

} 

Console. ReadKeyQ; 

} 

} 


Az alapelv ugyanaz, egyedüli újdonság a byte-tömb inicializálása. Most nem tudjuk pontosan, hogy milyen 
hosszú adatot kapunk a szervertől, ezért „tippelünk" (igazából tudjuk, de ez most nem számít). Ha nincs elég 
hely akkor nem kapunk kivételt, de a bejövő adatból csak annyit látunk viszont, amennyi a tömbben elfér. A 
NetworkStream Read metódusa hasonlóan működik a Write-hoz, viszont visszaadja a bejövő üzenet hosszát 
(byte-ban). 

Már ismerjük az alapokat, eljött az ideje, hogy egy szinttel lejjebb lépjünk a socketek világába. 
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using System; 
using System.Text; 
using System.Net.Sockets; 
using System.Net; 

namespace Serven 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

Socket server = null; 

Socket client = null; 

try 

{ 

server = new Socket( 

AddressFamily .InterNetwork, 

SocketType .Stream, 

ProtocolType.Tcp); 

IPEndPoint endPoint = new IPEndPoint( 

IPAddress. Pár se ("127.0.0.1") , 

5000); 

server.Bind(endPoint); 
server.Listen(2); 

client = server.Accept(); 

byte[] data = new byte[256]; 
int length = client.Receive(data); 

Console.WriteLine("A kliens üzenete: {0}", 

Encoding. ASCII.GetString(data, 0, length)); 

data = new byte[256]; 

data = Encoding. ASCII.GetBytes( "Hello kliens!"); 
client.Send(data, data.Length, SocketFlags .Nőne); 

} 

catch (Exception e) 

{ 

Console.WriteLine(e .Message); 

} 

finally 

{ 

client.Close(); 
server.Close(); 

} 

Console .ReadKey(); 

} 

} 

} 


A Socket osztály konstruktorában megadtuk a címzési módot (InterNetwork, ez az IPv4), a socket típusát 
(Stream, ez egy oda-vissza kommunikációt biztosító kapcsolat lesz) és a használt protokollt, ami jelen esetben 
TCP. A három paraméter nem független egymástól, pl. Stream típusú socketet csak TCP portokoll felett 
használhatunk. 
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Ezután készítettünk egy IPEndPoint objektumot, ahogyan azt az egyszerűbb változatban is tettük. Ezt a 
végpontot a Bind metódussal kötöttük a sockethez, majd a Listen metódussal megmondtuk, hogy figyelje a 
bejövó' kapcsolatokat. Ez utóbbi paramétere azt jelzi, hogy maximum hány bejövő kapcsolat várakozhat. 
Innentől kezdve nagyon ismerős a forráskód, lényegében ugyanazt tesszük, mint eddig, csak épp más a 
metódus neve. 

A kliens osztály sem okozhat nagy meglepetést: 


using System; 
using System.Net; 
using System.Net.Sockets; 
using System.Text; 

eláss Program 

{ 

static public void Main(string[ ] args) 

{ 

Socket Client = null; 

try 

{ 

Client = new Socket( 

AddressFamily .InterNetwork, 

SocketType .Stream, 

ProtocolType.Tcp) ; 

IPEndPoint endPoint = new IPEndPoint( 

IPAdd re ss. Pár se ("127.0.0.1")., 

5000); ; 

Client.Connect(endPoint); 
byte[] data = new byte [256]; 

data = Encoding. ASCII.GetBytes( "Hello szerver!"); 

Client.Send(data, data.Length, SocketFlags.None); 

data = new byte[256]; 

int length = Client.Receive(data); 

Console.WriteLine("A szerver üzenete: {0}", 

Encoding. ASCII.GetString(data, 0, length)); 

} 

catch (Exception e) 

{ 

Console.WriteLine(e.Message); 

} 

finally 

{ 

Client.Close(); 

} 

Console. ReadKey(); 

} 

} 


A különbséget a Connect metódus jelenti, mivel most kapcsolódni akarunk, nem hallgatózni. 
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Blokk elkerülése 


Az eddigi programjaink mind megegyeztek abban, hogy bizonyos műveletek blokkolták a főszálat, és így 
várakozni kényszerültünk. Ilyen művelet volt pl. az Accept/AcceptTcpCIient, de a Read/Receive is. 

A blokk elkerülésére ún. előre-ellenőrzést (prechecking) fogunk alkalmazni, vagyis megvizsgáljuk, hogy adott 
időpillanatban van-e bejövő adat, vagy ráérünk később újraellenőrizni, addig pedig csinálhatunk mást. 

A TcpListerner/TcpCIient osztályok a rájuk csatlakoztatott NetworkStream objektum DataAvailable 
tulajdonságán keresztül tudják vizsgálni, hogy jön-e adat vagy sem. A következő példában a kliens rendszeres 
időközönként ellenőrzi, hogy érkezett-e válasz a szervertől, és ha az eredmény negatív, akkor foglalkozhat a 
dolgával: 


bool 1 = false; 
while (II) 

{ 

if (stream.DataAvailable) 

{ 

data = new byte[256]; 

int length = stream.Read(data, 0, data.Length); 

Console.WriteLine( "A szerver üzenete: {0}"., 

Encoding. ASCII.GetString(dataj 0, length)); 

1 = true; 

} 

else 

{ 

Console.WriteLine( "A szerver még nem küldött választ!"); 
System.Threading.Thread.Sleep(200); 

} 


A ciklus egészen addig fut, amíg nincs bejövő kapcsolat, ezt az I változóval jelezzük. 

Ugyanezt a hatást socketek esetében a Socket osztály Available tulajdonságával érhetjük el, amely jelzi, hogy 
van-e még várakozó adat a csatornán (egészen pontosan azoknak a byte-oknak a számát adja vissza, amelyeket 
még nem olvastunk be): 


while (true) 

{ 

if (client.Available > 0) 

{ 

int length = client.Receive(data); 
Console.WriteLine( "A szerver üzenete: 

Encoding. ASCII.GetString(dataj 0 , length)); 
break; 

} 

else 

{ 

Console.WriteLine( "Várunk a szerver válaszára..."); 
System.Threading.Thread.Sleep(200); 

} 

} 


Itt egy másik módszert, egy végtelen ciklust választottunk a ciklus kezelésére, amikor érkezik bejövő adat, a 
break utasítással „kitörünk" belőle. A várakozás időszakában pedig 200 ezredmásodpercre megállítjuk a szálat. 

Most nézzük meg, hogy mi a helyzet szerveroldalon! Itt a tipikus probléma az, hogy az AcceptTcpCIient/Accept 
teljesen blokkol, amíg bejövő kapcsolatra várakozunk. Erre is van persze megoldás, a TcpListener esetében ezt 
a Pending , míg a Socket osztálynál a Poll metódus jelenti. 
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Nézzük elsőként a TcpListener -t: 


while (true) 

{ 

if (server.Pending()) 

{ 

Client = server.AcceptTcpClient(); 

Console.WriteLine( "Kliens kapcsolódott... "); 

stream = Client.GetStream(); 
byte[] data = new byte[256]; 

int length = stream.Read(data, 0 , data.Length); 

Console.WriteLine( "A kliens üzenete: {0}"., 

Encoding. ASCII.GetString(data, 0 , length)); 

data = Encoding. ASCII.GetBytes( "Hello kliens!"); 
stream.Write(data, 0 , data.Length); 

} 

else 

{ 

Console.WriteLine( "Most valami mást csinálunk"); 
System.Threading. Thread .Sleep(500); 

} 

} 


A Pending azt az információt osztja meg velünk, hogy várakozik-e bejövő kapcsolat. Tulajdonképpen ez a 
metódus a következő forrásban szereplő (a Socket osztályhoz tartozó) Poll metódust használja: 


while (true) 

{ 

if (server.Poll(0j SelectMode.SelectRead)) 

{ 

Client = server.Accept(); 

/* itt pedig kommunikálunk a klienssel */ 

} 

else 

{ 

Console.WriteLine( "A szerver bejövő kapcsolatra vár!"); 
System.Threading.Thread.Sleep(500); 

} 


A Poll metódus első paramétere egy egész szám, amely mikromásodpercben (nem milli-, itt valóban a 
másodperc milliomod részéről van szó, vagyis ha egy másodpercig akarunk várni, akkor 1000000-ot kell 
megadnunk) adja meg azt az időt, amíg várunk bejövő kapcsolatra/adatra. Amennyiben az első paraméter 
negatív szám, akkor addig várunk, amíg nincs kapcsolat (vagyis blokkoljuk a programot), ha pedig nullát adunk 
meg, akkor használhatjuk prechecking-re is a metódust. 

A második paraméterrel azt mondjuk meg, hogy mire várunk. A SelectMode felsorolt típus három taggal 
rendelkezik: 

• SelectRead: a metódus igaz értékkel tér vissza, ha meghívtuk a Listen metódust, és várakozik bejövő 
kapcsolat, vagy van bejövő adat, illetve ha a kapcsolat megszűnt; minden más esetben a visszatérési 
érték false lesz. 

• SelectWrite: igaz értéket kapunk vissza, ha a Connect metódus hívása sikeres volt, azaz csatlakoztunk 
a távoli állomáshoz, illetve ha lehetséges adat küldése. 

• SelectError: true értéket ad vissza, ha a Connect metódus hívása sikertelen volt. 
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Egy másik lehetőség a blokk feloldására, ha a Socket objektum Blocking tulajdonságát false értékre állítjuk. 
Ekkor a Socket osztály Récéivé és Send metódusainak megadhatunk egy SocketError típusú (out) paramétert, 
amely WouldBIock értékkel tér vissza, ha a metódushívás blokkot okozna (vagyis így újra próbálhatjuk 
küldeni/fogadni később az adatokat). Azt azonban nem árt tudni, hogy ez és a fenti Poll metódust használó 
megoldások nem hatékonyak, mivel folyamatos metódushívásokat kell végrehajtanunk (vagy a háttérben a 
rendszernek). A következő fejezetben több kliens egyidejű kezelésével sokkal hatékonyabb módszer(eke)t 
fogunk megvizsgálni. 


Több kliens kezelése 


Az eddigi programjainkban csak egy klienst kezeltünk, ami nagyon kényelmes volt, mivel egy sor dolgot 
figyelmen kívül hagyhattunk: 

• A kliensekre mutató „referencia" tárolása. 

• A szerver akkor is tudjon kapcsolatot fogadni, amíg a bejelentkezett kliensekkel foglalkozunk. 

• Minden kliens zavartalanul (lehetőleg blokk nélkül) tudjon kommunikálni a szerverrel és viszont. 

A következőkben háromféleképpen fogjuk körüljárni a problémát. 

Select 

Az első versenyzőnk a Socket osztály Select metódusa lesz, amelynek segítségével meghatározhatjuk egy vagy 
több Socket példány állapotát. Lényegében arról van szó, hogy egy listából kiválaszthatjuk azokat az elemeket, 
amelyek megfelelnek bizonyos követelményeknek (írhatóak, olvashatóak). A Select (statikus) metódus 
szignatúrája a következőképpen néz ki: 


static public void Select( 
IList checkRead, 

IList checkWrite, 

IList checkError, 
int microSeconds 

) 


Az első három paraméter olyan IList interfészt implementáló gyűjtemények (lényegében az összes beépített 
gyűjtemény ilyen, beleértve a sima tömböket is), amelyek Socket példányokat tartalmaznak. Az első 
paraméternek megadott listát olvashatóságra, a másodikat írhatóságra, míg a harmadikat hibákra ellenőrzi a 
Select, majd a feltételnek megfelelő listaelemeket megtartja a listában, a többit eltávolítja (vagyis ha 
szükségünk van a többi elemre is, akkor célszerű egy másolatot használni az eredeti lista helyett). Az utolsó 
paraméterrel azt adjuk meg, hogy mennyi ideig várjunk a kliensek válaszára (mikroszekundum). 

Készítsünk egy Select-et használó kliens-szerver alkalmazást! A kliens oldalon lényegében semmit nem 
változtatunk azt leszámítva, hogy folyamatosan üzenetet küldünk a szervernek (most csak egyirányú lesz a 
kommunikáció): 


Random r = new Random(); 
while (true) 

{ 

if (r.Next(1000) % 2 == 0) 

{ 

byte[] data = new byte[256]; 

data = Encoding. ASCII.GetBytes( "Hello szerven!"); 
Client.Send(data, data.Length, SocketFlags.None); 

} 

System.Threading. hread.Sleep(500); 
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Most nézzük a szervert: 


int i = 0; 

while (i < MAXCLIENT) 

{ 

Socket Client = server.Accept(); 
client List.Add (client); 

++i; 

} 

while (true) 

{ 

ArrayList copyList = new ArrayList(clientList); 
Socket. Select(copyList, null, null, 1000); 

foreach (Socket client in clientList) 

{ 

Program.CommunicateWithClient(client); 

} 

} 


A MAXCLIENT változó egy egyszerű egész szám, meghatározzuk vele, hogy maximum hány klienst fogunk 
kezelni. Miután megfelelő' számú kapcsolatot hoztunk létre, elkezdünk „beszélgetni" a kliensekkel. A ciklus 
minden iterációjában meghívja a Select metódust, vagyis kiválasztjuk, hogy melyik kliensnek van mondandója. 
A CommunicateWithClient statikus metódus a már ismert módon olvassa a kliens üzenetét: 


static public void CommunicateWithClient(Socket client) 

{ 

byte[] data = new byte[256]; 
int length = client.Receive(data); 

Console.WriteLine("A kliens üzenete: {0}", 

Encoding. ASCII.GetString(data, 0, length)); 

} 


Aszinkron socketek 

Kliensek szinkron kezelésére is felhasználhatjuk a Socket osztályt, lényegében az aszinkron delegate-ekre épül 
ez a megoldás. Az aszinkron hívható metódusok Begin és End előtagot kapnak, pl. kapcsolat elfogadására most 
a BeginAccept metódust fogjuk használni. 

A kliens ezúttal is változatlan, nézzük a szerver oldalt: 


while (true) 

{ 

done.ResetQ; 

Console.WriteLine("A szerver kapcsolatra vár..."); 
server.BeginAccept (Program. AcceptCallback, server); 
done.WaitOne(); 

} 


A done változó a ManualResetEvent osztály egy példánya, segítségével szabályozni tudjuk a szálakat. A Rését 
metódus alaphelyzetbe állítja az objektumot, míg a WaitOne megállítja (blokkolja) az aktuális szálat, amíg egy 
jelzést (a Set metódussal) nem kap. A BeginAccept aszinkron metódus első paramétere az a metódus lesz, 
amely a kapcsolat fogadását végzi, második paraméternek pedig átadjuk a szervert reprezentáló Socket 
objektumot. Tehát: meghívjuk a BeginAccept-et, ezután pedig várunk, hogy az AcceptCallback metódus 
visszajelezzen a főszálnak, hogy a kliens csatlakozott, és folytathatja a figyelést. Nézzük az AcceptCallback-ot: 
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static public void AcceptCallback(IAsyncResult ar) 

{ 

Socket Client = ((Socket)ar.AsyncState). EndAccept(ar); 
done.Set(); 

Console.WriteLine("Kliens kapcsolódott... 

StringState State = new StringStateQ ; 

State.Client = Client; 

Client.BeginReceive(state.Buffer, 0, State. BufferSize, 
SocketFlags.None, Program. ReadCallback, State); 

} 


A kliens fogadása után meghívtuk a ManualResetEvent Set metódusát, ezzel jeleztük, hogy kész vagyunk, 
várhatjuk a következő klienst (látható, hogy csak addig kell blokkolnunk, amíg hozzá nem jutunk a klienshez, az 
adatcsere nyugodtan elfut a háttérben). 

A StringState osztályt kényelmi okokból mi magunk készítettük el, ezt fogjuk átadni a BeginReceive 
metódusnak: 


eláss State 

{ 

public const int BufferSize = 256; 

public State() 

{ 

Buffer = new byte[BufferSize]; 

} 

public Socket Client { get; set; } 
public byte[] Buffer { get; set; } 

} 

eláss StringState : State 

{ 

public StringState() 

: base() 

{ 

Data = new StringBuilder( ); 

} 

public StringBuilder Data { get; set; } 

} 


Végül nézzük a BeginReceive callback metódusát: 


static public void ReadCallback(IAsyncResult ar) 

{ 

StringState State = (StringState)ar .AsyncState; 
int length = State.Client.EndReceive(ar); 

State.Data.Append(E ncoding. ASCII.GetString(state.Buffer, 0, length)); 
Console.WriteLine("A kliens üzenete: {0}", State.Data); 
state.Client.Close(); 

} 


A fordított irányú adatcsere ugyanígy zajlik, a megfelelő metódusok Begin/End előtagú változataival. 
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Szálakkal megvalósított szerver 

Ez a módszer nagyon hasonló az aszinkron változathoz, azzal a különbséggel, hogy most manuálisan hozzuk 
létre a szálakat, illetve nemcsak a beépített aszinkron metódusokra támaszkodhatunk, hanem tetszés szerinti 
műveletet hajthatunk végre a háttérben. 

A következő' programunk egy számkitalálós játékot fog megvalósítani úgy, hogy a szerver gondol egy számra és 
a kliensek ezt megpróbálják kitalálni. Minden kliens ötször találgathat, ha nem sikerül kitalálnia, akkor elveszíti 
a játékot. Mindent tipp után a szerver visszaküld egy számot a kliensnek: -1-et, ha a gondolt szám nagyobb, 1- 
et, ha a szám kisebb, O-át, ha eltalálta a számot és 2-t, ha valaki már kitalálta a számot. Ha egy kliens kitalálta a 
számot, akkor a szerver megvárja, míg minden kliens kilép, és új számot sorsol. 

Készítettünk egy osztályt, amely megkönnyíti a dolgunkat. A Listen metódussal indítjuk el a szervert: 


public void ListenQ 

{ 

if (EndPoint == null) 

{ 

thnow new Exception("IPEndPoint missing"); 

} 

serven = new Socket(AddressFamily. InterNetwork, 

SocketType .Stream, 

ProtocolType.Tcp); 

server.Bind(EndPoint); 
server.Listen(5); 

ThreadPool.SetMaxThreads(MaxClient, 0); 

NewTurnEvent += NewTurnHandler; 

Console.WriteLine("A szerver elindult, a szám: {0}", NUMBER); 

Socket Client = null; 
while (true) 

{ 

Client = server.Accept(); 

Console.WriteLine( "Kliens bejelentkezett, a következő IP címről: {0}", 
(( IPEndPoint) Client.RemoteEndPoint).Addréss.ToString()); 

ThreadPool.QueueUserWorkItem(ClientHandler, Client); 

} 

} 


A kliensek kezeléséhez a ThreadPool osztályt fogjuk használni, amelynek segítségével a kliens objektumokat 
átadjuk a ClientHandler metódusnak: 


priváté void ClientHandler(object socket) 

{ 

Socket Client = null; 
string name = String. Empty; 
int result = 0; 

try 

{ 

Client = socket as Socket; 

if (client == null) 

{ 

throw new ArgumentExceptionQ; 

} 
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++ClientNumber; 

byte[] data = new byte [7]; 

int length = Client.Receive(data); 

name = Encoding. ASCII.GetString(data, 0, length); 

Console.WriteLine( "Új játékos: {0}", name); 

int i = 0; 

bool win = false; 

while (i < 5 && win == false) 

{ 

data = new byte[128]; 
length = Client.Receive(data); 

GuessNumber(name, 

int. Parse(Encoding.ASCII.GetString(data, 0 , length)), 
out result); 

data = Encoding. ASCII.GetBytes(result.ToString()); 

Client.Send(data, data.Length, SocketFlags.None); 

if (result == 0) { win = true; } 

++i; 

} 

} 

catch (Exception e) 

{ 

Console.WriteLine(e.Message); 

} 

finally 

{ 

Client. Close(); 

if (--ClientNumber == 0 && result == 0) 

{ 

NewTurnEvent(this, null); 

} 

} 

} 


Minden kliens rendelkezik névvel is, amely 7 karakter hosszú (7 byte) lehet, elsőként ezt olvassuk be. A 
GuessNumber metódusnak adjuk át a tippünket és a result változót out paraméterként. Végül a finally 
blokkban ellenőrizzük, hogy van-e bejelentkezett kliens, ha pedig nincs, akkor új számot sorsolunk. Nézzük a 
GuessNumber metódust: 


priváté void GuessNumber(string name, int number, out int result) 
{ 


lock (locker) 

{ 

if (NUMBER != -1) 

{ 

Console.WriteLine( "{0} szerint a szám: {1}", name, number); 

if (NUMBER == number) 

{ 

Console .WriteLine( "{0} kitalálta a számot!", name); 
result = 0; 

NUMBER = -1; 

} 
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else if (NUMBER < number) 

{ 

result = 1; 

} 

else 

{ 

result = -1; 

} 

} 

else result = 2; 

} 

Thread.Sleep(300); 


A metódus törzsét le kell zárnunk, hogy egyszerre csak egy szál (egy kliens) tudjon hozzáférni. Ha valamelyik 
kliens kitalálta a számot, akkor annak -1-et adunk vissza, így gyorsan ellenőrizhetjük, hogy a feltétel melyik 
ágába kell bemennünk. 

Kliens oldalon sokkal egyszerűbb dolgunk van, ezt a forráskódot itt nem részletezzük, de megtalálható a 
jegyzethez tartozó források között. 


TCP És UDP 

Ez a fejezet elsődlegesen a TCP protokollt használta, de említést kell tennünk az Internet másik 
alapprotokolljáról, az UDP-ről is. 

A TCP megbízható, de egyúttal kicsit lassabb módszer. A csomagokat sorszámmal látja el, ez alapján pedig a 
fogadó fél nyugtát küld, hogy az adott csomag rendben megérkezett. Amennyiben adott időn belül a nyugta 
nem érkezik meg, akkor a csomagot újra elküldi. Ezenkívül ellenőrzi, hogy a csomagok sérülésmentesek 
legyenek, illetve kiszűri a duplán elküldött (redundáns) adatokat is. 

Az UDP épp az ellenkezője, nem biztosítja, hogy minden csomag megérkezik, cserében gyors lesz. Jellemzően 
olyan helyeken használják, ahol a gyorsaság számít, és nem nagy probléma, ha egy-két csomag elveszik, pl. 
valós idejű média lejátszásnál illetve játékoknál. 

A .NET a TCP-hez hasonlóan biztosítja számunkra az UdpListener/Client osztályokat, ezek kezelése 
gyakorlatilag megegyezik TCP-t használó párjaikkal, ezért itt most nem részletezzük. 

Hagyományos Socket-ek esetén is elérhető ez a protokoll, ekkor a Socket osztály konstruktora így fog kinézni: 


Socket sérvén = new Socket ( 

AddressFamily .InterNetwork, 
SocketType.Dgram, 
ProtocolType .Udp); 


Ezután ugyanúgy használhatjuk ezt az objektumot, mint a TCP-t alkalmazó társát. 
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LINQToObjects 


A C# 3.0 bevezette a LINQ-t (Language Integrated Query), amely lehetővé teszi, hogy könnyen, uniformizált 
úton kezeljük a különböző adatforrásokat, vagyis pontosan ugyanúgy fogunk kezelni egy adatbázist, mint egy 
memóriában lévő gyűjteményt. Miért jó ez nekünk? Napjainkban rengeteg adatforrás áll rendelkezésünkre, 
ezek kezeléséhez pedig új eszközök használatát illetve új nyelveket kell megtanulnunk (SQL a relációs 
adatbázisokhoz, XQuery az XML-hez stb.j.A LINQ lehetővé teszi, hogy egy plusz réteg (a UNQ „felület") 
bevezetésével mindezeket áthidaljuk, méghozzá teljes mértékben függetlenül az adatforrástól. Egy másik 
előnye pedig, hogy a LINQ lekérdezések erősen típusosak, vagyis a legtöbb hibát még fordítási időben el tudjuk 
kapni és kijavítani. 

A LINQ család jelenleg három főcsapást jelölt ki, ezek a következőek: 

• LINQTo XML: XML dokumentumok lekérdezését és szerkesztését teszi lehetővé. 

• LINQTo SQL (vagy DLINQ) és LINQTo Entities (Entity Framework): relációs adatbázisokon (elsősorban 
MS SQL-Server) végezhetünk műveleteket velük. A kettő közül a LINQTo Entites a „főnök", a LINQTo 
SQL inkább csak technológiai demónak készült, a Microsoft nem fejleszti tovább (de továbbra is 
elérhető marad, mivel kisebb projectekre illetve hobbifejlesztésekhez kiváló). Az Entity Framework 
használatához a Visual Stúdió 2008 első szervizcsomagjára van szükség. 

• LINQ To Objects: ennek a fejezetnek a tárgya, memóriában lévő gyűjtemények, listák, tömbök 
feldolgozását teszi lehetővé (lényegében minden olyan osztállyal működik, amely megvalósítja az 
IEnumerable<T> interfészt). 

A fentieken kívül számos third-party/hobbi project létezik, mivel a LINQ „framework" viszonylag könnyen 
kiegészíthető tetszés szerinti adatforrás használatához. 

A fejezethez tartozó forráskódok megtalálhatóak a Sources\LINQ könyvtárban. 


Nyelvi eszközök 

A C# 3.0-ban megjelent néhány újdonság részben a LINQ miatt került a nyelvbe, jelenlétük jelentősen 
megkönnyíti a dolgunkat. Ezek a következők: 

Kiterjesztett metódusok (extension method): velük már korábban megismerkedtünk, a LINQTo Objects teljes 
funkcionalitása ezekre épül, lényegében az összes művelet az IEnumerable<T>/IEnumerable interfészeket 
egészíti ki. 

Objektum és gyűjtemény inicializálók: vagyis a lehetőség, hogy az objektum deklarálásával egy időben 
beállíthassuk a tulajdonságaikat, illetve gyűjtemények esetében az elemeket: 


using System; 

using System.Collections.Generic; 


namespace Server 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

/^Objektum inicializáló*/ 

MyObject mo = new MyObject() 

{ 

Propertyl = "valuel", 
Property2 = "value2". 


}; 


/*Gyűjtemény inicializáló*/ 
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} 


} 


} 


List<string> üst = new List<string>() 

{ 

"alma"., "körte", "dió", "kakukktojás 

}; 


Lambda kifejezések: a lekérdezések többségénél nagyon kényelmes lesz a lambdák használata, ugyanakkor 
lehetó'ség van a „hagyományos" névtelen metódusok felhasználására is. 

A var: a lekérdezések egy részénél rendkívül nehéz előre megadni az eredménylista típusát, ezért ilyenkor a 
var-t fogjuk használni, bízzuk magunkat a fordítóra. 

Névtelen típusok: sok esetben nincs szükségünk egy objektum minden adatára, ilyenkor feleslegesen foglalná 
egy lekérdezés eredménye a memóriát. A névtelen típusok bevezetése lehetővé teszi, hogy helyben 
deklaráljunk egy névtelen osztályt: 


using System; 

namespace Server 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

var typel = new { Valuel = "alma", Value2 = "körte" }; 
Console.WriteLine(typel.Valuel); //alma 
Console .ReadKey(); 

} 

} 

} 


Kiválasztás 

A legegyszerűbb dolog, amit egy listával tehetünk, hogy egy vagy több elemét valamilyen kritérium alapján 
kiválasztjuk. A következő forráskódban épp ezt fogjuk tenni, egy egész számokat tartalmazó List<T> 
adatszerkezetből az összes számot lekérdezzük. Természetesen ennek így sok értelme nincsen, de szűrésről 
majd csak a következő fejezetben fogunk tanulni. 


using System; 

using System.Collections.Generic; 
using System.Linq; 

namespace Server 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

List<int> üst = new List<int>() 

{ 

10, 2, 4, 55, 22, 75, 30, 11, 12, 89 

var result = from number in üst select number; 
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foreach (van item in nesult) 

{ 

Console .WriteLine( "{0}" , item); 

} 

Console. ReadKeyQ; 

} 

} 

} 

Elsősorban vegyük észre az új névteret, a System.Linq-t. Rá lesz szükségünk mostantól az összes lekérdezést 
tartalmazó programban, tehát ne felejtsük le! Nem mintha lenne választásunk, hiszen ebben az esetben le sem 
fordulna a program. Most pedig jöjjön a lényeg, nézzük a következő sort: 

var result = from number in üst select numben; 

Egy UNQ lekérdezés a legegyszerűbb formájában a következő sablonnal írható le: 

eredmény = from azonosító in kifejezés select kifejezés 

A lekérdezés első fejében meghatározzuk az adatforrást: 

from azonosító in kifejezés 

Egészen pontosan a „kifejezés" jelöli a forrást, míg az „azonosító" a forrás egyes tagjait adja meg a kiválasztás 
minden iterációjában, lényegében pontosan ugyanúgy működik, mint a foreach ciklus: 

foreach(var azonosító in kifejezés) 

Vagyis a lekérdezés alatt a forrás minden egyes elemével tehetünk, amit jólesik. Ezt a valamit a lekérdezés 
második fele tartalmazza: 

select kifejezés 

A fenti példában egyszerűen vissza akarjuk kapni a számokat eredeti formájukban, de akár ezt is írhattuk volna: 

van nesult = fnom numben in üst select (numben + 10); 

Azaz minden számhoz hozzáadunk tízet. 

Az SQL -t ismerők számára furcsa lehet, hogy először az adatforrást határozzuk meg, de ennek megvan az oka, 
mégpedig az, hogy ilyen módon a fejlesztőeszköz (a Visual Stúdió) támogatást illetve típusellenőrzést adhat a 
select utáni kifejezéshez (illetve a lekérdezés többi részéhez). 

A fenti kódban SQL-szerű lekérdezést készítettünk (ún. Query Expression Formát), de máshogyan is 
megfogalmazhattuk volna a mondanivalónkat. Emlékezzünk: minden UNQ To Objects művelet egyben 
kiterjesztett metódus, vagyis ezt is írhattuk volna: 

van nesult = üst.Select(numben => numben); 


Pontosan ugyanazt értük el, és a fordítás után pontosan ugyanazt a kifejezést is fogja használni a program, 
mindössze a szintaxis más (ez pedig az Extension Method Formát; a fordító is ezt a formátumot tudja 
értelmezni, tehát a Query Syntax is erre alakul át). A Select az adatforrás elemeinek típusát használó Func<T, 
V> generikus delegate-et kap paraméteréül, jelen esetben ezt egy lambda kifejezéssel helyettesítettük, de 
írhattuk volna a következőket is: 
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var resultl = list.Select( 
delegate(int number) 

{ 

return number; 

}); 

Funccint, int> selector = (x) => x; 
var result2 = list.Select(selector); 


A két szintaxist keverhetjük is (Query Dót Formát), de ez az olvashatóság rovására mehet, ezért nem ajánlott 
(leszámítva olyan eseteket, amikor egy művelet csak az egyik formával használható). Fia csak lehet, 
ragaszkodjunk csak az egyikhez! 

A következő' példában a Distinct metódust használjuk, amely a lekérdezés eredményéből eltávolítja a duplikált 
elemeket. Őt csakis Extension Method formában hívhatjuk meg: 


using System; 

using System.Collections.Generic; 
using System.Linq; 

namespace Server 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

List<int> üst = new List<int>() 

{ 

1, 1, 3j S, 6, 6, 10, 11, 1 

}; 

var result = (from number in üst select number).Distinct(); 

foreach (var item in result) 

{ 

Console.WriteLine( "{0}" , item); 

} 

Console .ReadKey(); 

} 

} 

} 


A jegyzet ezután mindkét változatot bemutatja a forráskódokban. 

Projekció 

Vegyük a következő egyszerű „osztály-hierarchiát": 


eláss Address 

{ 

public string Country { get; set; } 
public int PostalCode { get; set; } 
public int State { get; set; } 
public string City { get; set; } 
public string Street { get; set; } 

} 

eláss Customer 
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{ 

public int ID { get; set; } 
public string FirstName { get; set; } 
public string LastName { get; set; } 
public string Email { get; set; } 
public string PhoneNumber { get; set; } 
public Address Address { get; set; } 

} 


Minden vásárlóhoz tartozik egy Address objektum, amely a vevő' címét tárolja. Tegyük fel, hogy egy olyan 
lekérdezést akarok írni, amely visszaadja az összes vevő nevét, e-mail címét és telefonszámát. Ez nem bonyolult 
dolog, a kód a következő lesz: 


var result = from customer in custList select customer; 

foreach(var customer in result) 

{ 

Console.WriteLine("Név: {0}, Email: {1}, Telefon: {2}", 
customer.FirstName + ” ” + customer.LastName, 
customer.Email, Customer. PhoneNumber); 

} 


A probléma a fenti kóddal, hogy a szükséges adatokon kívül megkaptuk az egész objektumot, beleértve a cím 
példányt is, amelyre pedig semmi szükségünk nincsen. A megoldás, hogy az eredeti eredményhalmazt 
leszűkítjük úgy, hogy a lekérdezésben készítünk egy névtelen osztályt, amely csak a kért adatokat tartalmazza. 
Ezt projekciónak nevezzük. Az új kód: 


var result = from customer in custList 
select new 
{ 

Name = customer.FirstName + Customer .LastName, 
Email = customer.Email, 

Phone = customer.PhoneNumber 

}; 


Természetesen nem csak névtelen osztályokkal dolgozhatunk ilyen esetekben, hanem készíthetünk specializált 
direkt erre a célra szolgáló osztályokat is. 


A lekérdezés eredményének típusát eddig nem jelöltük, helyette a var kulcsszót használtuk, mivel ez rövidebb. 
Minden olyan lekérdezés, amelytől egynél több eredményt várunk (tehát nem azok az operátorok, amelyek 
pontosan egy elemmel térnek vissza - erről később részletesebben), IEnumerable<T> típusú eredményt (vagy 
annak leszármazott, specializált változatát) ad vissza. 


Let 

A let segítségével - a lekérdezés hatókörén belüli - változókat hozhatunk létre, amelyek segítségével 
elkerülhetjük egy kifejezés ismételt felhasználását. Nézzünk egy példát: 


string[] poem = new string[] 

{ 

"Ej mi a kő! tyúkanyó, kend", 

"A szobában lakik itt bent?", 

"Lám, csak jó az isten, jót ád,", 

"Hogy fölvitte a kend dolgát!" 

}; 

var result = from line in poem 

let words = line.Split(' ') 
from word in words 
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select word; 


A let segítségével minden sorból egy újabb string-tömböt készítettünk, amelyeken egy belső' lekérdezést 
futtattunk le (tehát az eredménylistában az eredeti stringek szavai lesznek). 


Szűrés 

Nyílván nincs szükségünk mindig az összes elemre, ezért képesnek kell lennünk szűrni az eredménylistát. A 
legalapvetőbb ilyen művelet a where, amelyet a következő sablonnal írhatunk le: 


from azonosító in kifejezés where kifejezés select azonosító 


Nézzünk egy egyszerű példát: 


using System; 

using System.Collections.Generic; 
using System.Linq; 

namespace Serven 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

List<int> üst = new List<int>() 

{ 

12, 4, 56, 72, 34, 0, 89, 22 
}J 

var resultl = from number in üst 
where number > 30 
select number; 

var result2 = üst.Where(number => number > 30); 

var result3 = (from number in üst select number) 
.Where(number => number > 30); 

foreach (var item in resultl) 

{ 

Console.WriteLine(item); 

} 

Console .ReadKey(); 

} 

} 

} 


A forrásban mindhárom lekérdezés szintaxist láthatjuk, mind pontosan ugyanazt fogja visszaadni, és teljesen 
szabályosak. 

A where egy paraméterrel rendelkező, bool visszatérési értékű metódust (anonim metódust, lambda kifejezést 
stb.) vár paramétereként: 


Funccint, bool> predicate = (x) => x > 30; 

var resultl = from number in üst 

where predicate(number) 
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select number; 

var result2 = list.Where(predicate); 


A where feltételeinek megfelelő elemek nem a lekérdezés hívásakor kerülnek az eredménylistába, hanem 
akkor, amikor ténylegesen felhasználjuk őket, ezt elhalasztott végrehajtásnak (deferred execution) nevezzük (ez 
alól kivételt jelent, ha a lekérdezés eredményén azonnal meghívjuk pl. a ToList metódust, ekkor az elemek 
szűrése azonnal megtörténik). 

A következő példában teszteljük a fenti állítást: 


using System; 

using System.Collections.Generic; 
using System.Linq; 

namespace Server 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

List<int> list = new List<int>() 

{ 

12, 4, 56, 72, 34, 0, 89, 22 

Funceint, bool> predicate = (x) => 

{ 

Console.WriteLine("Szűrés. .. 
return x > 30; 

}; 

Console.WriteLine("Lekérdezés előtt.. ."); 

var result = from number in list 

where predicate(number) 
select number; 

Console.WriteLine("Lekérdezés után... "); 

foreach (var item in result) 

{ 

Console.WriteLine( "{0}", item); 

} 

Console .ReadKey(); 

} 

} 

} 


A kimenet pedig ez lesz: 


Lekérdezés előtt... 
Lekérdezés után... 
Szűrés... 

Szűrés... 

Szűrés... 

56 

Szűrés... 
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Jól látható, hogy a foreach ciklus váltotta ki a szűró' elindulását. A where két alakban létezik, az elsőt már láttuk, 
most nézzük meg a másodikat is: 


var result = list.Where^number, index) => index % 2 == 0); 


Ez a változat két paramétert kezel, ahol index az elem indexét jelöli, természetesen nullától számozva. A fenti 
lekérdezés a páros indexű elemeket választja ki. 

Ne használjuk a következő formát: 


var result = list.Select(x => x).Where(x => x > 10); 


Látszólag szabályos a lekérdezés, azonban a fordító a Select és Where számára is elkészít egy függvényt, holott 
a munkát egyedül a Where is elvégezné. így viszont egy plusz felesleges függvényhívás az eredmény. 

Rendezés 

A lekérdezések eredményét könnyen rendezhetjük az orderby utasítással, a lekérdezés sablonja ebben az 
esetben így alakul: 


from azonosító in kifejezés where kifejezés orderby tulajdonság ascending/descending select kifejezés 


Az első példában egyszerűen rendezzük egy számokból álló lista elemeit: 


var resultl = üst.OrderBy(x => x); // növekvő sorrend 

var result2 = from number in üst 

orderby number ascending 
select number; // szintén növekvő 

var result3 = from number in üst 

orderby number descending 
select number; // csökkenő sorrend 


A rendezés a gyorsrendezés algoritmusát használja. 

Az elemeket több szinten is rendezhetjük, a következő példában neveket fogunk sorrendbe rakni, mégpedig 
úgy, hogy az azonos kezdőbetűvel rendelkezőket tovább rendezzük a név második karaktere alapján: 


using System; 

using System.Collections.Generic; 
using System.Linq; 

namespace Server 

{ 

eláss Program 

{ 
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static void Main(string[ ] args) 

{ 

List<string> names = new List<string>( ) 

{ 

"Szandra", "István", "Iván", "Jolán", "lenő", "Béla", 
"Balázs", "Viktória", "Vazul", "Töhötöm", "Tamás" 

}; 

var resultl = names.OrderBy(name => name[0]) 

.ThenBy(name => name[l]); 

var result2 = from name in names 

orderby name[0], name[l] 
select name; 

foreach (var item in result2) 

{ 

Console.WriteLine(item); 

} 

Console .ReadKey(); 

} 

} 

} 


Az Extension Method formában a ThenBy volt segítségünkre, míg a Query szintaxissal csak annyi a dolgunk, 
hogy az alapszabály mögé írjuk a további kritériumokat. Egy lekérdezés pontosan egy orderby/OrderBy-t és 
bármennyi ThenBy-t tartalmazhat. 


Az OrderBy metódus egy másik változata két paramétert fogad, az első a rendezés alapszabálya, míg második 
paraméterként megadhatunk egy tetszőleges IComparer<T> interfészt megvalósító osztályt. 


Csoportosítás 


Lehetőségünk van egy lekérdezés eredményét csoportokba rendezni a group by/GroupBy metódus 
segítségével. A sablon ebben az esetben így alakul: 


from azonosító in kifejezés where kifejezés orderby tulajdonság ascending/descending group kifejezés by 
kifejezés intő azonosító select kifejezés 


Használjuk fel az előző fejezetben elkészített program neveit, és rendezzük őket csoportokba a név első betűje 
szerint: 


using System; 

using System.Collections.Generic; 
using System.Linq; 

namespace Serven 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

List<string> names = new List<string>( ) 

{ 

"Szandra", "István", "Iván", "Jolán", "Jenő", "Béla", 
"Balázs", "Viktória", "Vazul", "Töhötöm", "Tamás" 

}; 
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var resultl = names.OrderBy(name => name[0]) 
.GroupBy(name => name[0]); 

var result2 = from name in names 
orderby name[0] 
group name by name[0] 
intő namegroup 
select namegroup; 

foreach (var group in resultl) 

{ 

Console. WriteLine(group.Key); 

foreach (var name in group) 

{ 

Console. WriteLine("-- {0}", name); 

} 

} 

Console .ReadKey(); 

} 

} 

} 


A kimenet a következő lesz: 


B 

-- Béla 

— Balázs 
I 

-- István 
-- Iván 
J 

-- Jolán 
-- Jenő 
S 

— Szandra 
T 

- Töhötöm 
-- Tamás 

V 

-- Viktória 

- Vazul 


A csoportosításhoz meg kell adnunk egy kulcsot, ez lesz az OrderBy paramétere. Az eredmény típusa a 
következő lesz: 


IEnumerable<IGrouping<TKey, TEIement» 


Az IGrouping interfész tulajdonképpen maga is egy IEnumerable<T> leszármazott kiegészítve a rendezéshez 
használt kulccsal, vagyis lényegében egy lista a listában típusú „adatszerkezetről" van szó. 


Null értékek kezelése 
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Előfordul, hogy olyan listán akarunk lekérdezést végrehajtani, amelynek bizonyos indexein null érték van. A 
Select képes kezelni ezeket az eseteket, egyszerűen null értéket tesz az eredménylistába, de amikor rendezünk, 
akkor szükségünk van az objektum adataira, és ha null értéket akarunk vizsgálni, akkor gyorsan kivételt 
kaphatunk. Használjuk fel az előző programok listáját, egészítsük ki néhány null értékkel, és írjuk át a 
lekérdezést, hogy kezelje őket: 


var resultl = names.GroupBy(name => 

{ 

return name == null ? '0' : name[0]; 

}); 

var result2 = from name in names 
group name by 

name == null ? '0' : name[0] 
intő namegroup 
select namegroup; 

foreach (var group in result2) 

{ 

Console. WriteLine(group.Key); 

foreach (var name in group) 

{ 

Console.WriteLine("-- {0}"., name == null ? "null" : name); 

} 

} 


Többféle megoldás is létezik erre a problémára. Használhattuk volna a ?? operátort is, vagy akár készíthetünk 
egy metódust, amely a megfelelő alapértelmezett értéket adja vissza, a lényeg, hogy amikor a listában 
előfordulhatnak null értékek, akkor azt figyelembe kell venni a lekérdezés megírásakor. Ez akkor is számít, ha 
egyébként a lekérdezés nem végez műveleteket az elemekkel, hanem „csak" kiválasztást végzünk, hiszen az 
eredménylistában attól még ott lesznek a null elemek, amelyek később fejfájást okozhatnak. 

Összetett kulcsok 

Kulcs meghatározásánál lehetőségünk van egynél több értéket kulcsként megadni, ekkor névtelen osztályként 
kell azt definiálni. Használjuk fel a korábban megismert Customer illetve Address osztályokat, ezeket, illetve a 
hozzájuk tartozó listákat a jegyzet mellé csatolt forráskódok közül a Data.cs file-ban találja az olvasó. 


eláss Address 

{ 

public string Country { get; set; } 
public int PostalCode { get; set; } 
public int State { get; set; } 
public string City { get; set; } 
public string Street { get; set; } 

} 

eláss Customer 

{ 

public int ID { get; set; } 
public string FirstName { get; set; } 
public string LastName { get; set; } 
public string Email { get; set; } 
public string PhoneNumber { get; set; } 
public Address Address { get; set; } 

} 


A lekérdezést pedig a következőképpen írjuk meg: 
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using System; 

using System.Collections.Generic; 
using System.Linq; 

namespace Server 

{ 

eláss Program 

{ 

static void Main(string[] args) 

{ 

var result = from customer in DataClass .GetCustomerList() 
group customer by 
new 
{ 

customer.Address.Country, 
customer.Address.State 

} 

intő customergroup 
select customergroup; 

foreach (var group in result) 

{ 

Console.WriteLineC'ía}, {1}", 

group.Key.Country, group.Key.State); 

foreach (var customer in group) 

{ 

Console.WriteLine("-- {0}", 

customer.FirstName + " " + customer.LastName); 

} 

} 

Console .ReadKey(); 

} 

} 

} 


Listák összekapcsolása 


A relációs adatbázisok egyik alapköve, hogy egy lekérdezésben több táblát összekapcsolhatunk (jóin) egy 
lekérdezéssel, pl. egy webáruházban a vevő-áru-rendelés adatokat. Memóriában lévő gyűjtemények esetében 
ez viszonylag ritkán szükséges, de a LINQTo Objects támogatja ezt is. 

A join-műveletek azon az egyszerű feltételen alapulnak, hogy az összekapcsolandó objektumlisták rendelkeznek 
közös adattagokkal (relációs adatbázisoknál ezt elsődleges kulcs (primary key) - idegen kulcs (foreign key) 
kapcsolatként kezeljük). Nézzünk egy példát: 


eláss Customer 

{ 

public int ID { get; set; } 
public string FirstName { get; set; } 
public string LastName { get; set; } 
public string Email { get; set; } 
public string PhoneNumber { get; set; } 
public Address Address { get; set; } 

} 

eláss Order 

{ 

public int CustomerID { get; set; } 
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public int ProductID { get; set; } 
public DateTime OrderDate { get; set; } 
public DateTime? DeliverDate { get; set; } 
public string Note { get; set; } 

} 

eláss Product 

{ 

public int ID { get; set; } 

public string ProductName { get; set; } 

public int Quantity { get; set; } 

} 


Ez a fent említett webáruház egy egyszerű megvalósítása. Mind a Customer, mind a Product osztály rendelkezik 
egy ID nevű tulajdonsággal, amely segítségével egyértelműen meg tudjuk különböztetni őket, ez lesz az 
elsődleges kulcs (tegyük fel, hogy egy listában egy példányból - és így kulcsból - csak egy lehet). Az Order 
osztály mindkét példányra tartalmaz referenciát (hiszen minden rendelés egy vevő-termék párost igényel), ezek 
lesznek az idegen kulcsok. írjunk egy lekérdezést, amely visszaadja minden vásárló rendelését! Elsőként írjuk fel 
a join-nal felszerelt lekérdezések sablonját: 


from azonosító in kifejezés where kifejezés jóin azonosító in kifejezés on kifejezés equals kifejezés intő 
azonosító orderby tulajdonság ascending/descending group kifejezés by kifejezés intő azonosító select 
kifejezés 


Most pedig jöjjön a lekérdezés (az adatokat most is a Data.cs tárolja): 


var result = from order in DataClass.GetOrderList() 

jóin customer in DataClass.GetCustomerList() 
on order.CustomerID equals customer.ID 
select new 


{ 

}; 


Name = customer.FirstName + " " + customer.LastName, 
Products = DataClass.GetProductList() 

.Where(order.ProductID == product.ID) 


foreach (var orders in result) 

{ 

Console.WriteLine(orders.Name); 


foreach (var product in orders.Products) 

{ 

Console.WriteLine("-- {0}"., product.ProductName); 

} 


A jóin tipikusan az a lekérdezés típus, ahol az SQL-szerű szintaxis olvashatóbb, ezért itt csak ezt írtuk meg. A 
lekérdezés nagyon egyszerű: elsőként csatoltuk az elsődleges kulcsokat tartalmazó listát az idegen kulccsal 
rendelkező listához, majd megmondtuk, hogy milyen feltételek szerint párosítsa az elemeket (itt is 
használhatunk összetett kulcsokat ugyanúgy névtelen osztály készítésével). Az eredménylistát persze ki kell 
egészítenünk a vásárolt termékek listájával, ezért egy belső lekérdezést is írtunk. 

A kimenet a következő lesz: 


István Reiter 

— Elosztó 
István Reiter 

— Papírzsebkendő 
József Fekete 

— Elektromos vízforraló 
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OUTER JÓIN 


Az előző fejezetben azokat az elemeket választottuk ki, amelyek kapcsolódtak egymáshoz, de gyakran van 
szükségünk azokra is, amelyek éppen hogy nem kerülnének bele az eredménylistába, pl. azokat a „vásárlókat" 
keressük, akik eddig még nem rendeltek semmit. Ez a feladat a jóin egy speciális outer join-nak nevezett 
változata. A LINQTo Objects bár közvetlenül nem támogatja ezt (pl. az SQL tartalmaz OUTER JÓIN „utasítást"), 
de könnyen szimulálhatjuk a DefaultlfEmpty metódus használatával, amely egyszerűen egy null elemet helyez 
el az eredménylistában az összes olyan elem helyén, amely nem szerepelne a „hagyományos" jóin által kapott 
lekérdezésben. 

A következő példában a lekérdezés visszaadja a vásárlók rendelésének a sorszámát (most nincs szükségünk a 
Products listára), vagy ha még nem rendelt, akkor megjelenítünk egy „nincs rendelés" feliratot.: 


van nesult = fnom customen in DataClass .GetCustomenList() 
jóin onden in DataClass .GetOndenList() 
on customen.ID equals onden.CustomenlD intő tmpnesult 
fnom o in tmpnesult.DefaultlfEmpty() 
select new 
{ 

Name = customen.FinstName + ” " + customen.LastName, 

Pnoduct = o == null ? 

"nincs nendelés" : o.PnoductID.ToStning() 

}J 

foneach (van onden in nesult) 

{ 

Console.WniteLine("{0}: {1}", 
onden.Name, onden.Pnoduct); 

} 


Konverziós operátorok 

A LINQTo Objects lehetőséget ad listák konverziójára a következő operátorok segítségével: 

OfType és Cast: ők a „sima" lEnumerable interfészről konvertálnak generikus megfelelőikre, elsődlegesen a 
.NET 1.0-val való kompatibilitás miatt léteznek, hiszen a régi ArrayList osztály nem valósítja meg a generikus 
lEnumerable-t, ezért kasztolni kell, ha LTO -t akarunk használni. 

A kettő közti különbséget a hibakezelés jelenti: az OfType egyszerűen figyelmen kívül hagyja a konverziós 
hibákat, és a nem megfelelő elemeket kihagyja az eredménylistából, míg a Cast kivételt 
(System.InvalidCastException) dob: 


using System; 

using System.Collections.Genenic; 

using System.Linq; 

using System.Collections; 


namespace Senven 
{ 


eláss Pnognam 

{ 

static void Main(stning[] angs) 

{ 

AnnayList üst = new AnnayList(); 

list.Add("alma"); 
list.Add("dió"); 
üst. Add(12345); 
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var resultl = from item in list.Cast<string>() 
select item; 

var result2 = from item in list.OfType<string>() 
select item; 

foreach (var item in resultl) 

{ 

Console.WriteLine(item); // kivétel 

} 

Console.ReadKeyQ; 

} 

} 

} 


A program ugyan kiírja a lista első két elemét, de a harmadiknál már kivételt dob, tehát a konverzió elemenként 
történik, mégpedig akkor, amikor az eredménylistát ténylegesen felhasználjuk, nem pedig a lekérdezésnél. 

ToArray, ToList, ToLookup, ToDictionary: ezek a metódusok ahogyan a nevükből is látszik az IEnumerable<T> 
eredménylistát tömbbé vagy generikus gyűjteménnyé alakítják. A következő példában a ToList metódus 
látható: 


using System; 

using System.Collections.Generic; 

using System.Linq; 

using System.Collections; 

namespace Server 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

List<int> üst = new List<int>() 

{ 

10, 32, 45j 2, SS, 32, 21 

}; 

var result = (from number in üst 
where number > 20 
select number) .ToList<int>(); 

result.ForEach((number) => Console.WriteLine(number)); 

Console .ReadKey(); 

} 

} 

} 


Amikor ezeket az operátorokat használjuk, akkor a Where végrehajtása nem tolódik el, hanem azonnal kiszűri a 
megfelelő elemeket, vagyis itt érdemes figyelni a teljesítményre. 

A ToArray metódus értelemszerűen tömbbé konvertálja a bemenő adatokat. A ToDictionary és ToLookup 
metódusok hasonló feladatot látnak el abban az értelemben, hogy mindkettő kulcs-érték párokkal operáló 
adatszerkezetet hoz létre. A különbség a duplikált kulcsok kezelésében van: míg a Dictionary<T, V> szerkezet 
ezeket nem engedélyezi (sőt kivételt dob), addig a ToLookup ILookup<T, V> szerkezetet ad vissza, amelyben az 
azonos kulccsal rendelkező adatok listát alkotnak a listán belül, ezért őt kiválóan alkalmazhatjuk a jóin 
műveletek során. A következő példában ezt a metódust használjuk, hogy a vásárlókat megye szerint rendezze: 
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var result = (from customer in DataClass.GetCustomerList() 
select customer) 

.ToLookup((customer) => customer.Address.State + " megye"); 

foreach (var item in result) 

{ 

Console.WriteLine(item.Key); 

foreach (var customer in item) 

{ 

Console.WriteLine("-- {0} {1}", 

customer.FirstName, customer.LastName); 

} 

} 


A ToLookllp paramétereként a lista kulcsértékét várja. 

AsEnumerable: Ez az operátor a megfelelő IEnumerable<T> típusra konvertálja vissza a megadott 
IEnumerable<T> interfészt megvalósító adatszerkezetet. 


„Element”operátorok 

A következő operátorok megegyeznek abban, hogy egyetlen elemmel (vagy egy előre meghatározott 
alapértékkel) térnek vissza az eredménylistából. 

First/Last és FirstOrDefault/LastOrDefault: ezeknek a metódusoknak két változata van: a paraméter néküli az 
első/utolsó elemmel tér vissza a listából, míg a másik egy Func<T, bool> típusú metódust kap paraméternek, és 
e szerint a szűrő szerint választja ki az első elemet. Amennyiben nincs a feltételnek megfelelő elem a listában 
(vagy üres listáról beszélünk), akkor az első két operátor kivételt dob, míg a másik kettő az elemek típusának 
megfelelő alapértelmezett null értékkel tér vissza (pl. int típusú elemek listájánál ez nulla, míg stringek esetén 
null lesz): 


using System; 

using System.Collections.Generic; 
using System.Linq; 

namespace Serven 

{ 

eláss Program 

{ 

static void Main(string[ ] args) 

{ 

List<int> üst = new List<int>() 

{ 

10, 3, 56, 67, 4, 6, 78, 44 

}; 

var resultl = list.FirstQ; // 10 
var result2 = list.Last(); // 44 

var result3 = üst.First((item) => item > 10); // 56 

try 

{ 

var result4 = üst.Last((item) => item < 3); // kivétel 

} 

catch (Exception e) 

{ 

Console.WriteLine(e.Message); 
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} 

var result5 = üst.FirstOrDefault((item) => item < 3); // 0 

Console.WriteLine("{0}, {1}, {2}, {3}", 
resultl, result2, result3, resultS); 

Console .ReadKey(); 

} 

} 

} 


Single/SingleOrDefault: ugyanaz, mint a First/FirstOrDefault páros, de mindkettő kivételt dob, ha a feltételnek 
több elem is megfelel. 

ElementAt/ElementAtOrDefault: visszaadja a paraméterként átadott indexen található elemet. Az első kivételt 
dob, ha az index nem megfelelő, a másik pedig a megfelelő alapértelmezett értéket adja vissza. 

DefaultlfEmpty: a megfelelő alapértelmezett értékkel tér vissza, ha egy lista nem tartalmaz elemeket, őt 
használtuk korábban a jóin műveleteknél. 


Halmaz operátorok 

Nézzük a halmaz operátorokat, amelyek két lista közötti halmazműveleteket tesznek lehetővé. 

Concat és Union: mindkettő képes összefűzni két lista elemeit, de az utóbbi egy elemet csak egyszer tesz át az 
új listába: 


List<int> listl = new List<int>() 

{ 

10, 3, 56, 67, 4, 6, 78, 44 

}; 



List<int> list2 = new List<int>() 

{ 

10, 5, 67, 89, 3, 22, 99 

}; 



var resultl = listl.Concat(list2); 

/* 

10, 3, 56, 67, 4, 6, 78, 44, 

*/ 

10, 5, 67, 

89, 3, 22, 99 

var result2 = listl.Union(list2); 

/* 

10, 3, 56, 67, 4, 6, 78, 44, 

*/ 

5, 89, 22, 

99 


Intersect és Except: az első azokat az elemeket adja vissza, amelyek mindkét listában szerepelnek, míg a 
második azokat, amelyek csak az elsőben: 


List<int> listl = new List<int>() 

{ 

10, 3, 56, 67, 4, 6, 78, 44 

}; 

List<int> list2 = new List<int>() 

{ 
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10, 5, 67, 89, 3, 22, 99 

}; 

var resultl = üstl.Intersect(üst2); 

/* 

10, 3, 67 

*/ 

var result2 = listl.Except(list2); 

/* 

56, 4, 6, 78, 44 

*/ 


Aggregát operátorok 

Ezek az operátorok végigárnak egy listát, elvégeznek egy műveletet minden elemen, és végeredményként 
egyetlen értéket adnak vissza (pl. elemek összege vagy átlagszámítás). 

Count és LongCount: visszaadják az elemek számát egy listában. Alapértelmezés szerint az összes elemet 
számolják, de megadhatunk feltételt is. A két operátor közötti különbség az eredmény nagyságában van, a 
Count 32 bites egész számmal (int), míg a LongCount 64 bites egész számmal (int64) tér vissza: 


List<int> üst = new List<int>() 

{ 

10, 3, 56, 67, 4, 6, 78, 44 
}J 

var resultl = üst.Count(); // 8 

var result2 = üst.Count((item) => item > 10); // 4 


Min és Max: a lista legkisebb illetve legnagyobb elemét adják vissza. Mindkét operátornak megadhatunk egy 
szelektor kifejezést, amelyet az összes elemre alkalmaznak, és e szerint választják ki a megfelelő elemet: 


List<int> üst = new List<int>() 

{ 

10, 3, 56, 67, 4, 6, 78, 44 

}; 

var resultl = üst.Max(); // 78 

var result2 = üst.Max((item) => item % 3); // 2 


Természetesen a második eredmény maximum kettő lehet, hiszen hárommal való osztás után ez lehet a 
legnagyobb maradék. 

Mindkét metódus az IComparable<T> interfészt használja, így minden ezt megvalósító típuson használhatóak. 

Average és Sum: a lista elemeinek átlagát illetve összegét adják vissza. Ők is rendelkeznek szelektor kifejezést 
használó változattal: 


List<int> üst = new List<int>() 

{ 

10, 3, 56, 67, 4, 6, 78, 44 
}J 

var resultl = üst.Sum(); // 268 

var result2 = üst.Average(); // 33.5 

var result3 = üst.Sum((item) => item * 2); // 536 
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Aggregate: ez az operátor lehetővé teszi tetszőleges művelet elvégzését és a részeredmények „felhalmozását". 
Az Aggregate három formában létezik, tetszés szerint megadhatunk neki egy kezdőértéket, illetve egy szelektor 
kifejezést is: 


List<int> üst = new List<int>() 

{ 

1, 2, 3, 4 

}; 

van sum = list.Aggregate((nesult, item) => nesult + item); 

van max = üst.Aggnegate(-1, (nesult., item) => item > nesult ? item : nesult); 

van pencent = üst.Aggnegate(0.0, (nesult, item) => nesult + item, 
nesult => nesult / 100); 


Az első esetben a Sum operátort szimuláltuk, ezt nem kell magyarázni. A második változatban 
maximumkeresést végeztünk, itt megadtunk egy kezdőértéket, amelynél biztosan van nagyobb elem a listában. 
Végül a harmadik műveletnél kiszámoltuk a számok összegének egy százalékát (itt figyelni kell arra, hogy 
double típusként lássa a fordító a kezdőértéket, hiszen tizedes törtet akarunk visszakapni). A végeredményt 
tároló „változó" bármilyen típus lehet, még tömb is. 


PLINQ - PÁRHUZAMOS VÉGREHAJTÁS 

Egy korábbi fejezetben már megismerkedtünk a párhuzamos programozást támogató Task Parallel Library-val. 
Azonban a Microsoft nemcsak a „hagyományos" programok előtt nyitotta meg a párhuzamosság kapuját, 
hanem a LINQ lekérdezéseinket is felgyorsíthatjuk ezen a módon. 

PLINQ a gyakorlatban 

Hasonlítsuk össze a hagyományos és párhuzamos LINQ lekérdezések teljesítményét! Elsősorban szükségünk 
lesz valamilyen megfelelően nagy adatforrásra, amely jelen esetben egy szöveges fájl lesz. A könyvhöz mellékelt 
forráskódok között megtaláljuk a DataGen.es nevűt, amely az első paraméterként megadott fájlba a második 
paraméterként megadott mennyiségű vezetéknév-keresztnév-kor-foglalkozás-megye adatokat ír. A következő 
példában tízmillió személlyel fogunk dolgozni, tehát így futtassuk a programot: 


DataGen.exe E:\Data.txt 10000000 


Az elérési út persze tetszőleges. Most készítsük el a lekérdezést! Felhasználjuk, hogy a .NET 4.0-ban a 
File.ReadLines metódus IEnumerable<string>-gel tér vissza, vagyis közvetlenül hajthatunk rajta végre 
lekérdezést: 


van ünes = File.ReadLines(@"E:\Data.txt"); // System.10 kell 

van nesult = fnom üne in ünes 

let data = üne.Spüt(new chan[] { ' ' }) 

let name = data[l] 

let age = int.Panse(data[2]) 

let job = data[3] 

whene name == "István" && 

(age > 24 && age < 55) && 
job == "böntönőn" 
select üne; 
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Keressük az összes 24 és 55 év közötti István nevű börtönőrt. Elsőként szétvágunk minden egyes sort, majd a 
megfelelő indexekről (az adatok sorrendjéért látogassuk meg a DataGen.cs-t) összeszedjük a szükséges 
adatokat. Az eredményt írassuk ki egy egyszerű foreach ciklussal: 


foreach (var line in result) 

{ 

Console. WriteLine(line); 

} 


A fenti lekérdezés egyelőre nem párhuzamosított, nézzük meg, hogy mi történik: 



Ez a kép a processzorhasználatot mutatja. Két dolog világosan látszik: 1. a két processzormag nem ugyanazt a 
teljesítményt adja le, 2. egyik sem teljesít maximumon. 

Most írjuk át a lekérdezést párhuzamosra! Ezt rendkívül egyszerűen tehetjük meg, mindössze az AsParallel 
metódust kell meghívnunk az adatforráson: 


var result = from line in lines.AsParallel() 

let data = line.Split(new char[] { ' ' }) 

let name = data[l] 

let age = int.Parse(data[2]) 

let job = data[3] 

where name == "István" && 

(age > 24 && age < 55) && 
job == "börtönőr" 
select line; 


Lássuk az eredményt: 



A kép önmagáért beszél, de a teljesítménykülönbség is a tesztgépen átlagosan 25% volt a párhuzamos 
lekérdezés előnye a hagyományoshoz képest (ez természetesen mindenkinél más és más lehet). 


Az AsParallel kiterjesztett metódus egy ParalellQuery objektumot ad vissza, amely megvalósítja az 

lEnumerable interfészt. 


A kétoperandusú LINQ operátorokat (pl. jóin, Concat) csakis úgy használhatjuk párhuzamosan, ha mindkét 
adatforrást AsParallel-lel jelöljük, ellenkező esetben nem fordul le: 

var result = listl.AsParallel().Concat(list2.AsParallel()); 


Bár úgy tűnhet, hogy nagyon egyszerűen felgyorsíthatjuk a lekérdezéseinket, a valóság ennél kegyetlenebb. 
Ahhoz, hogy megértsük, hogy miért csak bizonyos esetekben kell párhuzamosítanunk, ismerni kell a 
párhuzamos lekérdezések munkamódszerét: 
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1. Analízis: a keretrendszer megvizsgálja, hogy egyáltalán megéri-e párhuzamosan végrehajtani a 
lekérdezést. Minden olyan lekérdezés, amely nem tartalmaz legalább viszonylag összetett szűrést vagy 
egyéb „drága" műveletet szinte biztos, hogy szekvenciálisán fog végrehajtódni (és egyúttal a 
lekérdezés futásidejéhez hozzáadódik a vizsgálat ideje is). Természetesen az ellenőrzést végrehajtó 
algoritmus sem tévedhetetlen, ezért lehetőségünk van manuálisan kikényszeríteni a párhuzamosságot 
a WithExecutionMode metódussal. 

2. Ha az ítélet a párhuzamosságra nézve kedvező, akkor a következő lépésben a feldolgozandó adatot a 
rendszer a rendelkezésre álló processzorok száma alapján elosztja. Ez meglehetősen bonyolult téma, 
az adatforrástól függően több stratégia is létezik, ezt itt nem részletezzük. 

3. Végrehajtás. 

4. A részeredmények összeillesztése. Erre a részre is lehet ráhatásunk, miszerint egyszerre szeretnénk a 
végeredményt megkapni, vagy megfelelnek a részeredmények is. Erre a célra a WithMergeOptions 
metódust kell meghívnunk a lekérdezésen. A paramétereként használatos ParallelMergeOptions 
felsorolás három taggal rendelkezik: a NotBuffered hatására azonnal visszakapunk minden egyes 
elemet a lekérdezésből, az AutoBuffered periodikusan ad vissza több elemet, mig a FullyBuffered csak 
akkor küldi vissza az eredményt, ha a lekérdezés teljesen kész van. 

Láthatjuk, hogy komoly számítási kapacitást igényel a rendszertől egy párhuzamos lekérdezés végrehajtása, épp 
ezért a nem megfelelő lekérdezések parallel módon való indítása nem fogja az elvárt teljesítményt hozni, 
tulajdonképpen még teljesítményromlás is lehet az eredménye. Tipikusan olyan helyzetekben akarunk ilyen 
lekérdezéseket használni, ahol nagy mennyiségű elemen sok vagy drága műveletet végzünk el, mivel itt 
nyerhetünk a legtöbbet. 

Rendezés 

Nézzük a következő kódot: 


List<int> üst = new List<int>() 

{ 

0, 1, 2, 2, 4, S, 6, 1, 8, 9 

}; 

var resultl = from x in üst select x; 

var result2 = from x in üst.AsParallel() select x; 


Vajon mit kapunk, ha kiíratjuk mindkét eredményt? A válasz meglepő lehet: 


resultl: 0, 1,2, 3, 4, 5, 6, 7, 8, 9 
result2: 0, 6, 3,4, 8, 2, 5, 1,9, 7 


Hogyan kaphattunk egy rendezett listából rendezetlen eredményt? A válasz nagyon egyszerű, hiszen tudjuk, 
hogy a PLINQ részegységekre bontja az adatforrást, vagyis nem fogjuk sorban visszakapni az eredményeket (a 
fent mutatott eredmény nem lesz mindenkinél ugyanaz, minden futásnál más sorrendet kaphatunk vissza). 
Amennyiben számít az eredmény rendezettsége, akkor vagy használnunk kell az orderby-t, vagy az AsParallel 
mellett meg kell hívnunk az AsOrdered kiterjesztett metódust: 


var result2 = from x in üst.AsParallel().AsOrdered() select x; 
var result3 = from x in üst.AsParallel() orderby x select x; 


A két lekérdezés hasonlónak tűnik, de nagy különbség van közöttük. Ha lemérjük a végrehajtási időt, akkor látni 
fogjuk, hogy az első valamivel gyorsabban végzett, mint a második, ennek pedig az az oka, hogy amíg az 
orderby mindig végrehajtja a rendezést, addig az AsOrdered egyszerűen megőrzi az eredeti sorrendet, és 
aszerint osztja szét az adatokat (nagy adatmennyiséggel a kettő közötti sebességkülönbség is jelentősen 
megnő, érdemes néhány ezer elemre is tesztelni). 
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Gyakran előfordul, hogy az eredeti állapot fenntartása nem előnyös számunkra, pl. kiválasztunk néhány elemet 
egy listából, és ezek alapján akarunk egy jóin műveletet végrehajtani. Ekkor nem célszerű fenntartani a 
sorrendet, használjuk az Asllnordered metódust, amely minden érvényes rendezést érvénytelenít! 


AsSequential 

Az AsSequential metódus épp ellenkezője az AsParallel-nek, vagyis szabályozhatjuk, hogy egy lekérdezés mely 
része legyen szekvenciális és melyik párhuzamos. A következő példában megnézzük, hogy ez miért jó nekünk. A 
PLINQ egyelőre még nem teljesen kiforrott, annak a szabályai, hogy mely operátorok lesznek mindig 
szekvenciálisán kezelve a jövőben valószínűleg változni fognak, ezért a példaprogramot illik fenntartással 
kezelni: 


van nesult = (fnom x in list.AsPanallel() select x).Take(10); 


Kiválasztjuk az eredménylistából az első tíz elemet. A probléma az, hogy a Take operátor szekvenciálisán fut 
majd le függetlenül attól, hogy mennyire bonyolult a „belső" lekérdezés, épp ezért nem kapunk semmiféle 
teljesítménynövekedést. írjuk át egy kicsit: 


van nesult2 = (fnom x in list.AsPanallelQ select x) 
.AsSequential().Take(10); 


Most pontosan azt kapjuk majd, amire várunk: a belső párhuzamos műveletsor végeztével visszaváltottunk 
szekvenciális módba, vagyis a Take nem fogja vissza a sebességet. 
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Grafikus felületű alkalmazások - Windows Forms 


Az eddigi fejezetekben „parancssoros" alkalmazásokat készítettünk, hogy a nyelv elemeinek megértésére 
koncentrálhassunk. Azonban a modern alkalmazások nagy része rendelkezik grafikus felülettel, amellyel 
kezelésük kényelmesebbé válik az átlagfelhasználók számára is. Számos lehetőségünk van ilyen programok 
készítésére, ebben a könyvben a Windows Forms könyvtárral ismerkedünk meg, ami meglehetősen egyszerűen 
elsajátítható! Ez a rendszer a .NET-tel szállított első grafikus interfész, tulajdonképpen a .Net előtti COM 
osztályokat burkolja be, hogy azok menedzselt környezetben legyenek használhatóak. 


„Hello Windows Forms" 

Készítsünk egy új projektet, Windows Forms Application sablonnal: 


New Project 


Recent Templates 

Sort by: 

Default ▼ | j| [|Ü] 


Installed Templates 






a Visual C# 

MwmLight (WP71) 

Visual C# 

Silverlight fór Windows Phone 

XNA Game Stúdió 4.0 

.31 

Windows Forms Application 

Visual C# 

Online Templates 

rtfi 

WPF Application 

Visual C# 


1 1 

3 

Console Application 

Visual C# 


fccfll 

Class Library 

Visual C# 


fcül 

WPF Browser Application 

Visual C# 


SI 

Empty Project 

Visual C# 


m 

Windows Game (4.0) 

Visual C# 



Windows Game Library (4.0) 

Visual C# 


S 

Xbox 360 Game (4.0) 

Visual C# 



Xbox 360 Game Library (4.0) 

Visual C# 


| Search Installed Templates 


Type: Visual C# 

A project fór creating an application with a 
Windows Forms user interface 


A projekt elkészülte után az ún. Design nézetbe kerülünk, ahol az alkalmazásunk látható, egyelőre még üresen. 
Ugyanakkor máris elindíthatjuk, bár sok haszna még nincsen. Érdemes ilyen projekt típusnál a képen látható 
módon megnyitni a Properties ablakot, hiszen az egyes vezérlők tulajdonságait itt könnyen beállíthatjuk. 


274 





















liíj WFDemo - Microsoft Visuai C# 2010 Express 


Fiié Edit View Project Build Debug Data Formát Tools Window Help 

i -a I is? * a [ 5Í «> iá | ő íj [S ít l ■o.jsjíssi s s: §; s: l; 


. 


"3 3 2S X ű & ü - , 



Mielőtt csinálnánk valami hasznosat, érdemes megnézni, hogyan épül fel egy ilyen projekt. Kattintsunk jobb 
gombbal a Design nézeten, és válasszuk a View Code menüpontot! Ekkor megjelenik az ún. code-behind fájl 
tartalma: 


using System; 

using System.Collections.Generic; 

using System.ComponentModel; 

using System.Data; 

using System.Dnawing; 

using System.Linq; 

using System.Text; 

using System.Windows.Fonms; 

namespace WFDemo 

{ 

public partial eláss Forrni : Form 

{ 

public Forml() 

{ 

InitializeComponentQ; 

} 

} 

} 


Két dolgot kell észrevennünk: az egyik, hogy ez egy parciális osztály, a másik pedig az, hogy a konstruktorban 
meghívtunk egy InitializeComponent nevű metódust, aminek a definícióját viszont nem látjuk. Ezt a metódust a 
fordító automatikusan generálja, és az ablakon szereplő vezérlők és az alkalmazás alapbeállításáért felelős. Ha a 
Solution Explorerben „lenyitjuk" a Forml.cs fájlt, láthatunk egy Forml.Designer.es nevű állományt is, amely 
nem más, mint a fent látható osztályunk másik fele. Ebbe a fájlba semmiképpen se írjunk, minden egyes 
fordításkor újragenerálódik, vagyis az általunk írt kód elveszne. Erre egyébként szükség sincsen, hiszen az 
általunk módosítható feléből ugyanúgy elérünk mindent, mint innen. 

Amennyiben a konstruktorban szeretnénk a program valamely tulajdonságán állítani azt mindenképpen az 
InitializeComponent hívás után tegyük meg, ellenkező esetben Nullreference kivételt kapunk, hiszen a vezérlők 
csak a futása után lesznek példányosítva. 

Nemcsak ennyiből áll azonban a projektünk: ha emlékszünk, minden .NET program tartalmaz egy Main 
függvényt is. Ezt a Program.es fájlban leljük meg: 
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using System; 

using System.Collections.Genenic; 

using System.Linq; 

using System.Windows.Forms; 

namespace WFDemo 

{ 

static eláss Program 

{ 

[STAThread] 

static void Main() 

{ 

Application. EnableVisualStyles(); 

Application.SetCompatibleTextRenderingDefault(false); 

Application. Run(new Forml()); 

} 

} 

} 


Most már elkészíthetjük az első „igazi" Windows Forms programunkat. Térjünk vissza a Design nézetbe, és 
hozzuk elő a ToolBox-ot, ez alapértelmezés szerint bal oldalt kell legyen, ha mégsem, akkor a Ctrl+W 
bíllentyűkombinációval csalogathatjuk elő. Az Autó Hide kikapcsolásával (kis rajzszög az ablak jobb fölső 
sarkában) rögzíthetjük is. Ebben az ablakban megtalálhatjuk az összes vezérlőt, amelyet felhasználhatunk, 
egyelőre elég lesz a Common Controls csoportban lévő gyűjtemény is: 


Toolbox ’ f X 

[> All Windows Forms * 

* Common Controls 
^ Pointer 
(ab) Button 
0 CheckBox 
13 CheckedListBox 
3 ComboBox 
‘ ffjfl DateTimePicker 
A Label 
A LinkLabel 
E3 ListBox 
ff 4 ListView 
0 MaskedTextBox 
MonthCalendar 
TTr] Notifylcon 
ÍT5 NumericUpDown 
PictureBox 
(QD ProgressBar 
0 RadioButton 
RichTextBox 
[abl; TextBox 
^ ToolTip 
r TreeView 
ú WebBrowser 
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Húzzunk egy Button, vagyis gomb vezérlőt az alkalmazásunkra: 


Toolbox 


0 All Windows Forms 
d Common Controls 


^ Pointer 
[áb) Button 
0 CheckBox 
m CheckedListBox 
T? ComboBox 
‘ Üfl DateTimePicker 
A Label 

A I inH ahpl 


Forrni.cs [Design]* 




A gombra kattintva a Properties ablakban a Text mezőben állítsuk be a feliratát: 


Properties 

’ ? X 

buttonl System.Windows.Forms.Buttc *■ 

|| N> 

Ili!!; 

Modifiers 

Priváté 

> 

Padding 

0; 0; 0; 0 


RightToLeft 

No 


!> Size 

75; 23 


Tablndex 

0 


TabStop 

True 


Tag 

Nyomj meg! [V 

§ 

TextAliqn 

MiddleCenter 

■w 

Text 

The text associated with the control. 



Helyezzünk el az ablakon még egy TextBox vezérlőt is, tetszőleges módon! Most pedig programozzunk egy 
kicsit! Azt szeretnénk elérni, hogy a gomb megnyomásakor valamilyen szöveg jelenjen meg a szövegmezőben. 
Valójában minden tudással rendelkezünk, amely ehhez a feladathoz szükséges, legalábbis ha már elolvastuk az 
Eseményekről szóló fejezetet. Ugyanis minden vezérlőhöz tartoznak események, amelyekre feliratkozva 
tetszőleges műveletet hajthatunk végre. Ha duplán kattintunk a gombon, a code-behind fájlba kerülünk, és 
megjelenik ott egy eseménykezelő metódus is buttonl_Click néven (minden vezérlő automatikusan nevet kap 
a vezérlő típusa+sorszám formában, ezt módosíthatjuk a Properties ablak Name mezőjében). 

A duplakattintás az adott vezérlő alapértelmezett eseményéhez készít eseménykezelőt, ez egy gomb esetén 
értelemszerűen a kattintás lesz. Más eseményekhez a Properties ablakban rendelhetünk eseménykezelőket, a 
kis villám gombra kattintva. 

Már csak annyi a dolgunk, hogy írunk valamit a TextBox-ba, ezt a Text tulajdonságán keresztül tudjuk 
megtenni: 


priváté void buttonl_Click(object sender, EventArgs e) 

{ 

textBoxl.Text = "Hello"; 

} 
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Vezérlők 


Vezérlők alatt azokat az elemeket értjük, amelyekből egy grafikus felület felépül. A legtöbb esetben valamilyen 
akciót hajthatunk végre rajtuk, például megnyomunk egy gombot, vagy írunk egy szövegmezőbe. Ebben a 
fejezetben megismerkedünk a leggyakrabban használt elemekkel. 

Form 

Minden Windows Forms alkalmazás alapja. Mivel a ContainerClass osztályból származik, képes magában más 
vezérlőket tárolni. A Form alapértelmezett eseménye a Load, amely azelőtt fut le, hogy a vezérlő megjelenne. 
Egy Formhoz kétféleképpen adhatunk vezérlőt, igaz a két módszer tulajdonképpen egy és ugyanaz. A 
legegyszerűbb, hogy a tervező nézetben egyszerűen ráhúzzuk a ToolBox-ból. A másik eset, amikor futásidőben 
forráskódból szeretnénk ezt megtenni. 

Ez utóbbihoz tudni kell, hogy minden ContainerClass-ból származó osztály rendelkezik egy Controls nevű 
tulajdonsággal, amely valójában az objektum vezérlőinek listája. Egy elemet a következőképpen adhatunk egy 
Form-hoz, pozíció és méret megadásával: 


Button button = new Button() 

{ 

Width = 100, 

Fleight = 30, 

Location = new Point(30, 40), 
Text = "Click" 

}; 

this .Controls.Add(button); 


A this itt a főablakra, vagyis az aktuális Form objektumra mutat. A Controls.Add egy Control objektumot vár, 
amely osztályból minden vezérlő származik. 

Button 

A gomb vezérlőt már ismerjük, elsődlegesen arra használjuk, hogy elindítsunk vele egy folyamatot, például 
adatokat mentsünk el. Alapértelmezett eseménye a kattintás. 

Láb el 

A felhasználó által nem módosítható szöveges tartalmat jeleníthetünk meg vele. Értékét a TextBox-hoz 
hasonlóan a Text tulajdonságán keresztül adhatjuk meg. 



A Label speciális változata a LinkLabel, amellyel hivatkozást adhatunk meg. Alapértelmezett eseménye a 
LinkCIicked, ahol átirányíthatjuk a felhasználót a kiválasztott helyre. 
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TextBox 


Szintén szöveges vezérlő, de képes fogadni a felhasználó billentyűleütéseit. MultiLine tulajdonságát true 
értékre állítva több sort is megjelenít. A PasswordChar tulajdonságának értékül adott karaktert jeleníti meg 
minden más karakter helyett, így jelszómezőként funkcionál. 

■9 Forrni L-EElLÜUBÖBI 


Ez egy sima TextBox 

Multi Une = 
true 


Alapértelmezett eseménye a TextChanged, amely a vezérlő tartalmának megváltozásakor fut le. 

ListBox 

Ez olyan vezérlő, amelyben jellemzően listákat tárolunk. Egy ListBox-ot feltölthetünk az Items tulajdonságán 
keresztül (akár a Properties ablakban), vagy pedig ún. adatkötéssel (data binding). Ehhez a DataSource 
tulajdonságot használjuk fel. Generáljuk le a Form Load eseményét, majd írjuk a következőt: 


priváté void Forml_Load(object sender, EventArgs e) 

{ 

string[] items = new string[] 

{ 

"István", "Szandra", "Béla", "Balázs" 

}; 

listBoxl.DataSource = items; 

} 


Amikor a DataSource tulajdonságot használjuk, a ListBox az elemek ToString metódusát hívja meg, hogy elkérje 
a megjelenítendő információt. Amennyiben a felhasznált osztályunk nem valósítja ezt meg (override 
használatával), akkor az elemek típusát adja vissza. 


r Forrni I | l~l IfTlT 



A ListBox alapértelmezett eseménye a SelectedlndexChanged, amely akkor fut le, ha megváltozott a 
vezérlőben a kijelölt elem. Az aktuális kiválasztott elemet a Selectedltem segítségével érjük el, ez object 
típussal tér vissza, tehát konvertálni kell, ha további terveink vannak vele. A kiválasztott elem indexét (nullától 
kezdve) a Selectedlndex tulajdonság tárolja. 

Az Items tulajdonsága hagyományos listaként viselkedik, használhatjuk rajta például a foreach ciklust is. A 
SelectionMode tulajdonságát megváltoztatva több elemet is kijelölhetünk egyszerre. Ez egy enum típus, 
értékei lehetnek Nőne (nem lehet kiválasztani egy elemet sem), MultiSimple (a Ctrl billentyű nyomva 
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tartásával lehet több elemet kiválasztani) illetve MultiExtended (az egér nyomva tartása mellett lehet 
„kijelölni" az elemeket). 

CheckBox 

Ez a vezérlő a választás lehetőségét kínálja. Tulajdonképpen egy jelölőnégyzetről van szó, amely segítségével 
egy vagy több opció közül választhatunk. Alapértelmezett eseménye a CheckedChanged, amelyet a 
bejelölés/visszavonás vált ki. A Checked tulajdonságán keresztül kérdezhetjük le, hogy be van-e jelölve vagy 
sem. 


Forrni 


Ez egy CheckBox 



Helyezzünk el a programunkban még egy Label-t is, amelynek feliratát annak függvényében változtassuk, hogy 
a CheckBox be van-e jelölve vagy sem (a Label Text tulajdonságát állítsuk üres stringre a program futásának 
elején)! Ezután kezeljük a CheckedChanged eseményt: 


priváté void checkBoxl_CheckedChanged(object sender, EventArgs e) 

{ 

if (checkBoxl.Checked) 

labell.Text = "A CheckBox be van jelölve!"; 

else 

labell.Text = "A CheckBox nincs bejelölve!"; 

} 


bJ Forrni 


=. (H) S 


[7] Ez egy CheckBox 
A CheckBox be van jelölve! 


RadioButton 

Hasonló funkcionalitást kínál, mint a CheckBox, de egy adott tárolón belül (pl. Form) több ilyen vezérlő egy 
csoportot alkot, és egy időben csak egy darab lehet bejelölve. Alapértelmezett eseménye a CheckedChanged. 


o Egyik © Másik 



Egy Formon belül előfordulhatnak önálló RadioButton csoportok, amelyeket valahogy el kell különíteni 
egymástól. Erre a célra Panel vagy GroupBox vezérlőket használhatunk, előbbi görgethető, de nem 
rendelhetünk hozzá feliratot, utóbbi fix és lehet „fejlécet" megadni hozzá. Ezeket a vezérlőket a ToolBox 
Containers fülén találjuk meg. 

Az alábbi képen GroupBox és Panel vezérlőkben helyeztünk el két-két RadioButton-t. Látható, hogy előbbi eset 
látványosabb, hiszen a GroupBox kerettel is rendelkezik, míg a Panel gyakorlatilag láthatatlan. 
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Ez egy Group Box 
o Egyik 
Másik 


Egyik 
o Másik 


Ha szeretnénk lekérdezni a RadioButton-t tároló elemet (ez lehet GroupBox, Form, bármely vezérlő', amely 
képes tárolni más vezérlőket), azt a Parent tulajdonságon tehetjük meg. Egy csoporton belül érdemes ugyanazt 
az eseménykezelőt rendelni az összes RadioButton-hoz, ezt úgy tehetjük meg, hogy kijelöljük egyesével a 
vezérlőket (Ctrl nyomva tartva és bal egérgomb), majd a Properties ablakban a „villám" gombbal előhozzuk a 
választható események listáját, és a kívánt elemen duplán kattintunk: 


Properties 


▼ ^ X 


: ,1 =j / 

AutoSizeChangi 

BackColorChan 

Backgroundlma 

Backgroundlma 

BindingContext 

CausesValidatio 

ChangeUICues 

Click 



CheckedChanged 

Occurs wheneverthe 'checked' property 
changes value. 


Ezután a sender paraméteren elvégezve a megfelelő típuskonverziót visszakapjuk azt a vezérlőt, amely az 
eseményről értesítőt küldött: 


priváté void radioButtonl_CheckedChanged(object sender, EventArgs e) 

{ 

RadioButton radioButton = (RadioButton)sender; 

} 


ComboBox 

Ez a vezérlő a TextBox és a ListBox egyfajta kombinációjának tekinthető, a beírt szöveg alapján kiválaszthatunk 
egy elemet egy előre megadott listából. Az adatok feltöltése ugyanúgy zajlik, mint a ListBox esetén (Properties 
ablak vagy DataSource tulajdonság). 


priváté void Forml_Load(object sender, EventArgs e) 

{ 

string[] items = new string[] 

{ 

"Szandra", "István", "Béla", "Balázs" 

}; 
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comboBoxl.DataSource = items; 

} 


r 

□9 Forrni 


1 

1 «a 

István 

Béla 

Balázs 


1 


Alapértelmezett eseménye a SelectedlndexChanged, amely az aktuális elem változását jelöli. A kiválasztott 
elemet illetve indexét a ListBox-szal megegyező módon kérdezhetjük le. 

NumericUpDown 

Ezzel a vezérlővel egy adott számtartományból választhatunk ki egy értéket. A Minimum és Maximum 
tulajdonságaival a legkisebb illetve legnagyobb lehetséges számot, míg az Increment propertyvel a léptéket 
állíthatjuk be. 


■9 Forrni 
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17 


Alapértelmezett eseménye a ValueChanged, amelyet a mutatott érték változása vált ki. 

ProgressBar 

A ProgressBar egy folyamat jelölésére szolgál. A NumericUpDown-hoz hasonlóan a Maximum, Minimum és 
Step tulajdonságokkal állíthatjuk értékeit. Helyezzünk el az alkalmazásunkban egyet, állítsuk a Step értéket 1- 
re, és tegyünk mellé egy gombot is! A gomb eseménykezelőjébe írjuk a következőt: 


priváté void buttonl_Click(object sender, EventArgs e) 

{ 

fór (int i = 0; i < 100; ++i) 

{ 

progressBarl.PerformStep(); 

System.Threading. Thread .Sleep(100); 

} 

} 


A PerformStep metódus a Step érték szerint lépteti a vezérlőt. 


□9 Forrni 


Ln,u=üfc*ai 



Minden lépésben pihentetjük kicsit a főszálat, hogy lelassítsuk a folyamatot. 
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PictureBox 


Ezt a vezérlőt képek megjelenítésére használjuk. Kétféleképpen adhatjuk meg a kívánt elemet: a 
tervezőnézetben a vezérlőn megjelenő kis nyilat „kinyitva" a Choose Image menüpontban az Import gombokkal 
választhatunk beágyazott illetve külső erőforrásból. Van egy másik lehetőségünk is: forráskódból egy Image 
objektumot rendelhetünk az Image tulajdonságához. 


priváté void Forml_Load(object sender, EventArgs e) 

{ 

Image img = new Bitmap("Desent. jpg"); 
pictureBoxl.Image = img; 

} 


Alapértelmezett eseménye a kattintás. 

RichTextBox 

A TextBox-hoz hasonlóan szöveges bevitelre alkalmas, ám annál lényegesen rugalmasabb és több lehetőséget 
is nyújt. Szöveget rendelhetünk hozzá a Text tulajdonságán keresztül, txt vagy rtf fájlokból. Ez utóbbi esetben a 
különféle formázásokat (betűszín, betűtípus stb.) is támogatja. Alapértelmezett eseménye a TexChanged. 

Az AppendText metódussal a már létező tartalomhoz tudunk hozzáfűzni karaktereket. Fájlokat a LoadFile 
metódussal tölthetünk be. Ennek párja a SaveFile, amellyel több formátumba is menthetünk: 


// szöveges állomány 

nichTextBoxl.SavéFile( "test.txt", RichTextBoxStreamType .PlainText); 
//rtf fáfl 

richTextBoxl.SaveFile( "test.rtf", RichTextBoxStreamType .RichText); 


A vezérlő lehetőséget ad a szöveg formázásához is, ehhez a Font tulajdonságát állíthatjuk, ekkor az összes 
létező szöveg formázása megváltozik. Fia csak a kijelölt szöveget szeretnénk állítani, akkor a SelectionFont 
tulajdonságon keresztül tehetjük ezt meg. 


Font font = new Font("Arial", 12 , FontStyle.Bold); 
richTextBoxl.SelectionFont = font; 


Ugyanígy dolgozhatunk a többi Selection előtagú tulajdonsággal. 


,□ Forrni I ■=■ B 23 


Ez egy szöveg a RichTextBox vezériőben 


[71 Félkövér O Dőlt 


DateTimePicke 

Ezzel a vezérlővel lehetőségünk van egy adott dátum kiválasztására. 
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Tulajdonképpen két részből áll, egy TextBox és egy gomb, amellyel megjeleníthetjük a naptárat, illetve maga a 
naptár vezérlő. Alapértelmezett eseménye a ValueChanged: 


priváté void dateTimePickerl_ValueChanged(object sender, EventArgs e) 

{ 

MessageBox.Show(dateTimePickerl.Value.ToString()); 

} 


A Value tulajdonsága DateTime típussal tér vissza. 

MenuStrip 

Menüsort készíthetünk vele, a Toolbox-ban a Menüs & ToolBars szekcióban találjuk meg. A tervező nézetben 
azonnal fel is tölthetjük elemekkel, illetve a helyi menüt kinyitva beállíthatjuk a megjelenését, illetve hogy hol 
helyezkedjen el. Az egyes menüpontokhoz (amelyek ToolStripMenultem típusúak) eseménykezelőt 
rendelhetünk (az ő alapértelmezett eseményük a kattintás). 


priváté void subMenulToolStripMenuItem_Click(object sender, EventArgs e) 

{ 

ToolStripMenultem menü = (ToolStripMenultem) sender; 
MessageBox.Show(menu.Text ); // kiírjuk a mneü feliratát 

} 



Párbeszédablakok 

Használhatunk előre megírt dialógusablakokat, mint például a fájl megnyitása/elmentése. A lehetséges 
ablakokat megtaláljuk a ToolBox-ban is a Dialogs szekcióban, és ráhúzhatjuk őket az alkalmazásunkra, ekkor 
azok osztálytagként elérhetővé válnak. Azonban célszerűbb őket helyben példányosítani, csakis akkor, ha 







































szükség van rájuk. Ezt a következőképpen tehetjük meg (feltesszük, hogy egy gomb megnyomásakor megnyílik 
az adott ablak): 


priváté void buttonl_Click(object sender, EventArgs e) 

{ 

using (OpenFileDialog dialóg = new OpenFileDialogQ ) 

{ 

if (dialóg.ShowDialog() == System.Windows.Forms .DialogResult. OK) 

{ 

MessageBox. Show(dialóg.FileName); 

} 

} 

} 


Az OpenFileDialog lehetőséget ad kiválasztani egy fájlt. A ShowDialog hívásakor megjelenik a fájlválasztó ablak. 
Minden művelet (OK gomb, ablak bezárása stb.) egy DialogResult felsorolás-típusú eredményt ad vissza, ebben 
az esetben csak arra vagyunk kíváncsiak, hogy a felhasználó megnyit egy fájlt. A FileName illetve FileNames (ha 
több fájlt nyitunk meg) a fájlok nevét adja vissza teljes elérési úttal. 
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Gyakorló feladatok V. 


Számológép 

Készítsünk számológép alkalmazást, amely Windows Forms alatt fut! A programnak két számon kell elvégeznie 
az alapműveleteket. 

Megoldás 

Készítsünk egy új projektet, és váltsunk tervező nézetbe! Húzzunk 15 gombot és egy TextBox-ot az ablakra, 10- 
et a számoknak, négyet az alapműveletek és egyet az egyenlőségjel részére, a szövegmezőben pedig a képletet 
és az eredményt jelenítjük majd meg. Valahogy így kell most kinéznie a programunknak: 


r 

» a Calc 

CD (°) 

87 





B B B B B 
BBBB B 
BBBBB 


Jelöljük ki az összes számot tartalmazó gombot, kivéve az egyenlőségjelet tartalmazót, és rendeljük hozzájuk 
ugyanazt az eseménykezelőt (Click): 


priváté void buttonl3_Click(object sender, EventArgs e) 

{ 

textBoxl.Text += ((Button)sender).Text; 

} 


Nem csinálunk itt mást mint, hogy hozzáfűzzük a szövegdobozhoz a soron következő karaktert. Egy 
hibalehetőség, hogy bizony több „operátor karaktert" is beírhatunk így, ezt az olvasónak kell megoldania, 
egyszerű feltétellel. 

Az eredményt egy külön eseménykezelőben számoljuk ki, amit az egyenlőség gombhoz rendelünk: 


priváté void buttonl5_Click(object sender, EventArgs e) 

{ 

int opldx = textBoxl.Text.IndexOfAny(new char[] { '*' }); 

int x = int. Parse(textBoxl.Text.Substring(0, opldx)); 
int y = int. Parse(textBoxl.Text.Substring(opIdx + 1)); 

int result = 0; 

switch(textBoxl.Text[opIdx]) 

{ 

case : 

result = x + y; 
break; 
case ' -' : 

result = x - y; 
break; 
case ' : 
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result = x / y; 
break; 
case ' : 

result = x * y; 
break; 

} 

textBoxl.Text += "=" + result; 

} 


Az első sorban meghatározzuk az operátor indexét a stringben, hogy szétválaszthassuk a számokat, amit a 
második és harmadik sorban teszünk meg a Substring függvénnyel. Figyeljünk az indexekre, a második szám az 
operátor indexe után következik! Végül egy switch szerkezettel kiszámoljuk az eredményt. 



9*34=306 
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Szövegszerkesztő 

Készítsünk egyszerű szövegszerkesztő programot, amellyel betölthetünk, illetve elmenthetünk 
dokumentumokat, illetve legyen lehetőség alapvető formázásokra is! 

Megoldás 

Helyezzünk el a tervező nézetben egy MenuStrip illetve egy RichTextBox vezérlőt, hogy az alábbi képhez 
hasonló eredményt kapjunk: 


Q ü 

Writer 




Megnyitás Mentés 

Formázás 

-il 



Dőlt 




Félkövér 



Készítsük el az egyes menüpontokhoz az eseménykezelőjüket (Click)l A Megnyitás menüpont: 
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priváté void openToolStripMenuItem_Click(object sender, EventArgs e) 

{ 

using (OpenFileDialog dialóg = new OpenFileDialogQ ) 

{ 

dialóg.Filter = "Szöveges Fájlok| *.txt|RTF Fájlok|*.rtf|All Files|*.*"; 

if (dialóg.ShowDialog() == System.Windows.Forms .DialogResult. OK) 

{ 

richTextBoxl.LoadFiié(dialóg.FileName); 

} 

} 

} 


A Filter tulajdonság segítségével megadhatjuk, milyen fájltípusok jelenjenek meg a dialógusablakban. Jöjjön a 
Mentés: 


priváté void saveToolStripMenuItem_Click(object sender, EventArgs e) 

{ 

using (SaveFileDialog dialóg = new SaveFileDialogQ ) 

{ 

if (dialóg.ShowDialog() == System.Windows.Forms .DialogResult. OK) 

{ 

richTextBoxl.SavéFiié(dialóg.FileName); 

} 

} 

} 


Végül a két „formázó" menüpont: 


priváté void italicToolStripMenuItem_Click(object sender, EventArgs e) 

{ 

FontStyle style = FontStyle. Italic; 

richTextBoxl.SelectionFont = new Font(richTextBoxl.Font, style); 

} 

priváté void boldToolStripMenuItem_Click(object sender, EventArgs e) 

{ 

FontStyle style = FontStyle. Bőid; 

richTextBoxl.SelectionFont = new Font(richTextBoxl.Font, style); 

} 


Az alkalmazás tetszőlegesen kiegészíthető a fentiek mintájára. Javasolt fejlesztések: betűtípus megadása, 
betűméret állítása, nyomtatás stb.). 
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